Extraction pour intégration continue

Question

Que faites-vous normalement lorsque vous vérifiez le code du logiciel de contrôle de version pour effectuer votre intégration continue ou votre build nocturne? Est-ce que vous 1) tirez le dernier code, ou 2) tirez par un tag (c'est-à-dire FONCTIONNEL) qui représente le dernier code du développeur à tester?

Je suppose que la réponse à cette question dépend de la façon dont les gens utilisent normalement leurs référentiels de gestion de configuration. Avez-vous l'intention de ne stocker que le code qui est "complet". Si tel est le cas, si un développeur travaille sur une tâche pendant une semaine, il ne sera pas en mesure de vérifier quoi que ce soit jusqu'à ce que la tâche soit complètement terminée. Si le serveur d'intégration continue, cependant, tirait simplement par une balise bien connue au lieu de tirer le dernier code, cela permettrait aux développeurs de vérifier le code très fréquemment car ils travaillent pour stocker un historique de leur travail en cours. Ensuite, une fois qu'ils étaient à l'aise avec les changements, ils pouvaient marquer leur nouveau code avec la balise FUNCTIONAL.

Je voulais juste connaître les meilleures pratiques.

Merci

Answer 1

donc ce que nous faisons habituellement est une branche « construire » que le serveur CI construit au large. Nous fusionnons tout ce que nous voulons être inclus dans la construction de nuit dans la branche de construction et il va construire là-bas.

Nous ne développons pas réellement la branche de construction, nous avons des branches de développement qui sont utilisées pour garder les changements qui ne sont pas prêts à être libérés dans les environnements de test.

Answer 2

Les principales recommandations que je mettrais pour un CI (plus comme règles de base):

1. Demandez à tirer le code de la HEAD/MASTER. Faites votre HEAD/MASTER toujours le plus tard possible et aussi que possible.
2. Personne ne peut commettre de code brisé au HEAD/MASTER. Si cela arrive, signifie que quelqu'un a cassé la construction.
3. Celui qui casse la construction doit être promis de le réparer dès que possible .
4. Demandez à votre CI d'exécuter les générations sur une base de . Donc, dès que quelqu'un commet un code brisé à la tête , le CI l'obtiendra et cassera la construction. La plupart des serveurs du CI que j'ai vu supportent ce modus operandi.
5. Vous pouvez également avoir votre CI à générer des builds nocturnes et marquer le code lorsqu'ils génèrent les packages . C'est aussi une bonne pratique , et vous pouvez voir cela en allant sur de nombreux CI à partir de projets open-source à travers le monde.

Une partie de mon expérience: Notre CI obtient le code du HEAD/MASTER. Nous utilisons git ici, donc il est toujours très facile pour nos développeurs de travailler sur des branches et de les synchroniser - mais ils ne peuvent que commettre du code stable sur HEAD/MASTER.

Answer 3

La bonne réponse dépend de la façon dont vous organisez votre code.

Si la ligne principale est toujours supposée stable/fonctionnelle, alors vous construisez simplement à partir de cela.

Si vous avez une branche qui est la « or » branche, puis ...

Dans notre boutique, nous avons trois types de branches:

• réseau principal // toujours inconstructible, toujours " prêt à libérer une fois QA est fait »
• branches // sortie d'or, sorti et relâchez-mesure à tout moment
• branches de développement // où la chirurgie se fait désordre

(Bien sûr, pour bien faire cela prend un bon vcs. Nous utilisons forcément, qui a la ramification impressionnante.)

Nous faisons notre bâtiment continu des branches principales et de dégagement.

HTH