Nous avons une installation de TeamCity 7.1 qui construit toutes les branches d'un référentiel GitHub.
Github a une notification raccrochre à TeamCity pour déclencher une construction sur l'enregistrement. Nous avons également des sondages sur TeamCity Github toutes les 120 secondes pour rechercher des modifications (au cas où le serveur était hors ligne lorsqu'un changement a été vérifié).
Notre développement normal suit un modèle commun:
Tout fonctionne bien (après de nombreuses recherches pour obtenir les paramètres de configuration corrects) cependant ...
Le processus ci-dessus déclenche plusieurs constructions sur TeamCity et j'aimerais savoir s'ils sont tous nécessaires. Généralement, nous allons nous retrouver avec:
Naturellement, la première version est le dernier enregistrement sur la branche particulière et la deuxième version est la requête de traction, mais
3 Réponses :
Vos constructions semblent redondantes. Le moyen plus économe d'organiser des constructions d'équipe de branches de fonctionnalités dans Git est la suivante:
Refs / Heads / Master Branche. Le sondage de 120 secondes est assez raisonnable ici.
- Organiser des constructions nocturnes pour chaque
Refs / Têtes / Nom de fonctionnalité Branches. À partir de mon expérience, seules quelques-unes des branches de fonctionnalité nécessitent une interrogation de 120 secondes.
TeamCity 7.1 a une très belle fonctionnalité pour les branches Autotrigger des fonctionnalités, de sorte que l'étape (2) peut être configurée en quelques clics avec un masque de branche comme refs / têtes / fonctionnalité - * . / p>
Il n'y a aucune signification dans la construction de demandes de tirage car elles seront couvertes par des constructions principales.
En ce qui concerne les demandes de tirage de la construction, la nouvelle API d'état Github Build Status nous permet d'afficher le statut de construction pour une demande de traction directement sur GitHub, qui est une épileuse massive. Cela se présente lorsque nous construisons la branche / pulls / 1 / tête de tête.
Pour les personnes intéressées, l'un des paramètres clés que nous avons modifiés était la spécification de la succursale comme ci-dessus (légèrement modifiée) et supprimé la construction de la gâchette sur chaque option d'enregistrement causant la plupart de nos maux de tête.
Troisième construction est en fait la plus précieuse - c'est le résultat de la fusion automatique de la demande de retrait (fusion qui se produit, lorsque vous appuyez sur le bouton de Github).
Cela signifie également que la fusion de Master dans la branche de la demande de traction est redondante.
réponse mise à jour, au cas où quelqu'un utilise toujours TeamCity 😉
Depuis 2018, il y a un natif Fonction de la requête de la requête de tirage . Il s'agit d'une meilleure solution par rapport à l'utilisation de déclencheurs et de filtres de branche, car elle crée une liaison à deux voies entre la construction et les relations publiques correspondantes et libère de devoir ajouter tout Néanmène, si vous insistez sur l'utilisation de refs / tire / tirant / ... à la spécification de la branche VCS.
Tirez / * / Fusionner : Notez que cela crée des constructions superflues
8 ans plus tard, je suis heureux que quelqu'un se soucie suffisamment pour répondre avec des informations mises à jour! Gloire.
Typiquement, cela ne serait pas un problème, mais la gestion de notre suite de tests ROR avec des tests d'intégration prend environ 10 minutes, nous ne recevons donc pas de commentaires sur le statut de construction sur les demandes de traction pendant 30 minutes maximum.