J'ai été confronté au problème de la mise à l'échelle de l'IC dans mon entreprise et en même temps, j'ai essayé de déterminer quelle approche adopter en ce qui concerne l'IC et les branches multiples. Il y a une question similaire à stackoverflow, plusieurs branches de fonctionnalités et intégration continue . J'en ai commencé un nouveau parce que j'aimerais avoir plus de discussion et fournir une analyse dans la question.
Jusqu'à présent, j'ai trouvé qu'il y a 2 approches principales que je peux prendre (ou peut-être quelques autres ???).
- Plusieurs ensembles d'emplois (parler de Jenkins / Hudson ici) par branche
- Rédiger des outils pour gérer les travaux supplémentaires
- Créer / modifier / supprimer des jobs en masse
- Paramètres personnalisés pour chaque travail par branche (URL SCM, duplications des dépôts de gestion des dépôts)
- Quelques exemples de personnes s'attaquant à ce problème avec les outils shell, les scripts ant et la CLI Jenkins. Voir:
- http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html
- http://jenkins.361315.n4.nabble.com/Is-it-possible-to-handle-multiple-branches-where-some-jobs-should-run-on-each-one-without-duplicatin-td954729. html
- http://jenkins.361315.n4.nabble.com/Parallel-development-with-branches-td1013013.html
- Configurer ou créer automatiquement une tâche Hudson
- Causera plus de charge sur votre cluster CI
- Le cycle de rétroaction pour les développeurs ralentit (si l'infrastructure ne peut pas gérer la nouvelle charge)
- Rédiger des outils pour gérer les travaux supplémentaires
- Plusieurs ensembles de travaux par 2 branches (développement et stabilité)
- Gérez les deux ensembles manuellement (si vous changez la conf d'un job alors assurez-vous de changer dans l'autre branche)
- PITA mais au moins si peu à gérer
- Les autres branches supplémentaires ne recevront pas de suite de tests complète avant d'être poussées vers le développement
- Développeurs insatisfaits. Pourquoi un développeur devrait-il se soucier des problèmes de mise à l'échelle CI? Il a une simple demande, quand je branche je voudrais tester mon code. Facile.
- Gérez les deux ensembles manuellement (si vous changez la conf d'un job alors assurez-vous de changer dans l'autre branche)
Donc, il semble que si je veux fournir aux développeurs des CI pour leurs propres branches personnalisées, j'ai besoin d'outils spéciaux pour Jenkins (API ou shellscripts ou quelque chose?) Et gérer la mise à l'échelle. Ou je peux leur dire de fusionner plus souvent avec DEV et de vivre sans CI sur des branches personnalisées. Laquelle choisiriez-vous ou y a-t-il d'autres options?