La gestion simultanée de plusieurs branches de l'intégration continue

J'ai du faire avec le problème de la mise à l'échelle CI dans mon entreprise et dans le même temps à essayer de comprendre l'approche à prendre quand il s'agit de CI et de multiples branches. Il y a une question similaire à stackoverflow, De multiples branches et d'intégration continue. J'ai commencé un nouveau parce que je voudrais avoir plus de discussion et de fournir une analyse de la question.

Jusqu'à présent, j'ai trouvé qu'il y a 2 approches principales que je peux prendre (ou peut-être quelques autres???).

Il semble donc que si je veux que les devs avec CI pour leurs propres branches j'ai besoin d'outils spéciaux pour Jenkins (API ou de scripts ou quelque chose?) et la poignée de mise à l'échelle. Ou je peux leur dire de fusionner plus souvent de DEV et de vivre sans CI sur les branches. Laquelle aimeriez-vous prendre ou existe-il d'autres options?

InformationsquelleAutor toomasr | 2011-04-10
  1. 69

    Quand vous parlez de mise à l'échelle CI que vous parlez vraiment de mise à l'échelle de l'utilisation de votre serveur CI pour répondre à tous vos branches avec votre réseau principal. Au départ, cela ressemble à une bonne approche que les développeurs dans une branche bénéficiez de tous les avantages de l'automatisation des tests que le CI parmi les emplois. Cependant, vous rencontrerez des problèmes de gestion du serveur CI emplois (comme vous l'avez découvert) et, plus important encore, vous n'êtes pas vraiment en train de faire CI. Oui, vous utilisez un serveur CI, mais vous n'êtes pas en permanence intégrer le code à partir de l'ensemble de vos développeurs.

    Réel CI, tous les développeurs sont en train de commettre régulièrement à la canalisation principale. Facile à dire, mais le plus dur est de le faire sans casser votre application. Je vous recommande vivement de regarder La Livraison Continue, en particulier la Garder Votre Demande Détachable section dans Chapitre 13: Gestion des Composants et des Dépendances. Les points principaux sont:

    • Masquer les nouvelles fonctionnalités que c'est fini (A. K. A Fonction Bascule).
    • Faire toutes les modifications au fur et à mesure d'une série de petits changements, dont chacun est libérable.
    • Utilisation de la branche par l'abstraction de faire des changements à grande échelle de la base de code.
    • D'utiliser des composants à découpler les parties de votre application que le changement à des taux différents.

    Ils sont assez explicites à l'exception de la branche par l'abstraction. C'est juste un terme de fantaisie pour:

    1. Créer une abstraction au-dessus de la partie du système que vous avez besoin de changer.
    2. Refactoriser le reste du système à l'utilisation de la couche d'abstraction.
    3. Créer une nouvelle mise en œuvre, ce qui n'est pas une partie de la production de code chemin jusqu'à complète.
    4. Mise à jour de votre couche d'abstraction de déléguer à votre nouvelle mise en œuvre.
    5. Enlever la vieille mise en œuvre.
    6. Enlever la couche d'abstraction si elle n'est plus appropriée.

    Le paragraphe suivant de l' Branches, les Ruisseaux, et d'Intégration Continue section dans Chapitre 14: Avancée de Contrôle de Version résume les impacts.

    L'approche incrémentale a certes besoin de plus de discipline et de soins - et, en effet, plus de créativité que de la création d'une direction générale et de la plongée gung-ho dans la re-création de l'architecture et de développer de nouvelles fonctionnalités. Mais il réduit considérablement le risque de vos changements de casser l'application, et d'enregistrer vous et votre équipe, beaucoup de temps à la fusion, la fixation de la casse, et l'obtention de votre application dans un déploiement de l'état.

    Il faut tout un changement de mentalité à abandonner les branches et vous bénéficiez toujours de la résistance. Dans mon expérience, cette résistance est basé sur les développeurs de ne pas se sentir en sécurité commettre code le la voie principale, et c'est une préoccupation raisonnable. Ce à son tour, généralement due à un manque de connaissances, de la confiance ou de l'expérience avec les techniques mentionnées ci-dessus et, éventuellement, avec le manque de confiance avec vos tests automatisés. L'ancien peut être résolu avec de la formation et de support de développeur. Ce dernier est beaucoup plus difficile à gérer, mais la ramification ne fournit pas de supplément de sécurité réel, c'est juste reporte le problème jusqu'à ce que les développeurs se sentent suffisamment en confiance avec leur code.

    • Tom, cela ne fonctionne bien que si 1) la version et mise à jour sont relativement facile, 2) la plupart de vos modifications sont bien isolées. Cela est vrai pour le web dev, mais si vous faites la boîte contenant le produit libère alors des versions stables rester stable à tous les coûts, de provoquer des correctifs sont vraiment coûteux, voire impossible dans un grand environnement de l'entreprise.
    • réel CI n'est pas seulement à propos de l'intégration, il est également au sujet de la rétroaction
    • J'ai choisi ce que la réponse (au moins donné la prime, s'il vous plaît laissez-moi savoir si j'ai encore besoin de le marquer correct) mais je pense que ce n'est pas une solution pour mon problème. J'ai écrit une suite à zeroturnaround.com/blog/...
    • Kabanov et @toomasr les Deux d'entre vous semblent supposer que de faire vrai CI signifie renoncer à la qualité et il travaille pour le Web dev seulement, car il est si facile de pousser des corrections. Je suppose que ce qui vous inquiète, c'est un peu louches commettre juste avant une libération. Oui, cela peut entraîner un mauvais dégagement qui peut être coûteux à corriger. Cependant un peu louches s'engager sur une branche juste avant il est sorti est tout aussi mauvais. Si vous sentez qu'il y a une différence s'il vous plaît partagez votre raisonnement. Une façon de lutter contre cela, (si la validation a été à la canalisation principale ou une branche) est d'utiliser la Prestation Continue de l'approche.
    • Oh, et BTW, pour les plus de 4 ans de ma principale expérience de développement a été dans les institutions financières. L'impératif de disposer de versions stables et le coût de faire des erreurs (pour ne pas mentionner le changement contol processus à suivre pour faire sortir un correctif) n'est pas beaucoup plus que cela. Une boîte contenant le produit serait un changement reposant pour moi.
    • Les défis avec les coffrets sont presque toujours liée au fait qu'ils doivent travailler dans l'environnement non contrôlé. Ceci est compliqué par le fait que nous avons deux produits à partir de la même base de code avec différents cycles de publication. Je vais regarder dans la Livraison Continue, mais je ne suis pas trop optimiste à ce sujet.
    • Kabano yep, les environnements non contrôlés sont difficiles à travailler avec, mais je ne vois pas comment SCM ramification aide. Aussi, vous avez fait l'appel dans votre premier commentaire que celui CI ne fonctionne que lorsque les modifications sont bien isolées. CI est encore plus important lorsque vos modifications ne sont pas bien isolés et qu'il vous permet de composer avec les changements que d'autres personnes font comme ils se produisent, et non pas lors de certains gros laid fusionner vers le bas de la piste, ils vous n'avez aucun moyen d'estimer combien de temps ou combien complexe, il sera.
    • il semble que vous n'avez pas marqué comme la réponse correcte.
    • Marqué comme bon maintenant, désolé. Bizarre, c'est que j'ai coché la case pour être averti par e-mail sur d'autres commentaires, mais seulement aujourd'hui, je n'ai trébucher sur les 4 derniers commentaires. Rien dans mon dossier spam soit. De toute façon, l'affaire est close maintenant.
    • des acclamations. Aussi, j'ai lu votre article à zeroturnaround et je pense que vous pouvez vous poser la mauvaise question. Vous pourriez essayer de "gérer plusieurs branches dans automatisée construit" à la place. Je vous conseille d'éviter toute mention de CI, car il semble que n'est pas ce que vous voulez faire.

    InformationsquelleAutor Tom Howard
  2. 4

    Je voudrais configurer des tâches distinctes pour chaque branche. J'ai fait cela avant et il n'est pas difficile à gérer et à configurer si vous avez configuré Hudson/Jenkins correctement. Un moyen rapide de créer des emplois multiples est de copier à partir d'un travail existant qui a les mêmes exigences et les modifier au besoin. Je ne suis pas sûr si vous voulez permettre à chaque développeur de créer son propre emploi pour leurs propres branches, mais il n'est pas beaucoup de travail pour une personne (c'est à dire un build manager) pour gérer. Une fois que la coutume des branches ont été fusionnées dans la stable les branches, les emplois correspondants peuvent être enlevés lorsqu'ils ne sont plus nécessaires.

    Si vous êtes inquiet au sujet de la charge sur le serveur CI, vous pourriez mettre en place des instances distinctes de l'IC ou même séparer les esclaves pour aider à équilibrer la charge sur plusieurs serveurs. Assurez-vous que le serveur vous sont en cours d'exécution Hudson/Jenkins est adéquate. J'ai utilisé Apache Tomcat et juste eu à s'assurer qu'il a suffisamment de mémoire et de puissance de traitement pour traiter l'accumulation de la file d'attente.

    Il est important d'être clair sur ce que vous voulez réaliser à l'aide de l'IC, et puis trouver un moyen de la mettre en œuvre sans trop d'effort manuel ou de duplication. Il n'y a rien de mal avec l'aide d'autres outils externes ou des scripts qui sont exécutés par votre serveur CI qui contribuent à simplifier l'ensemble du processus de gestion.

    • Je pense que ce manque d'outillage signifie qu'il y a de la place pour certains plugins/produits dans ce département. N'aurait pas envie d'écrire mes propres.
    • Il y a utilitaire pour Jenkins qui crée de la configuration de build pour chaque branche automatiquement: entagen.github.com/jenkins-build-per-branch
    InformationsquelleAutor Bernard
  3. 3

    J'ai choisi de dev+stable branches. Et si vous voulez toujours la coutume de branches et de la peur de la charge, alors pourquoi ne pas déplacer ces personnalisées pour le cloud et permettent aux développeurs de gérer eux-mêmes, par exemple http://cloudbees.com/dev.cb
    C'est la société où kohsuke nous est maintenant.
    Il y a une Éclipse de l'Outillage aussi, donc si vous êtes sur Eclipse, vous l'aurez étroitement intégré au sein de dev env.

    • Vais-je être la négociation de l'absence de l'outillage de la gestion de plusieurs branches d'avoir le même problème, mais sur le cloud? Je veux dire, je vais être en mesure de gérer la charge de travail maintenant, mais toujours pas les branches?
    • Je voulais oublier l'outillage et de distribuer la gestion parmi les développeurs - "si vous voulez une mesure personnelle de construire, voici votre CB compte". Sans affecter la génération de performance du serveur principal. Bien que leur API est assez simple, en créant de gestion utils serait une question de une-deux semaines probablement, et puis que vous y faites ce que vous voulez. Comme il est habituel dans la vie, si vous voulez quelque chose de spécial que vous êtes mieux de le faire vous-même. En même temps, ils sont en croissance rapide et à l'écoute de la communauté, afin de remplir une demande de fonctionnalité et peut-être qu'il apparaît bientôt.
    • Oh, compris. Dire la direction de la propriétaire de la cerise choisir l'emploi qu'il est intéressé et de les mettre en place pour sa coutume branche comme il veut. J'aime cette idée.
    InformationsquelleAutor Anton Safonov
  4. 1

    Fait ce qui est vraiment problématique, c'est construire l'isolement avec des branches. Dans notre entreprise, nous avons un ensemble de séparer les projets maven tous partie d'une plus grande distribution. Ces projets sont gérés par différentes équipes, mais pour chaque distribution de tous les projets doivent être libérés. Un featurebranch peut maintenant se chevauchent d'un projet à l'autre et c'est alors construire l'isolement devient douloureusement. Il existe plusieurs solutions, nous avons essayé:

    • créez un instantané de dépôts dans le nexus pour chaque branche
    • partager des espaces de stockage locaux dédiés esclaves
    • utiliser le référentiel-serveur-plugin avec en amont des référentiels
    • construire au sein d'un même travail avec un repository privé

    Comme une question de fait, la dernière solution est la plus prometteuse. Toutes les autres solutions de manque dans l'une ou l'autre manière. Avec le travail-dsl plugin, il est facile pour l'installation d'une nouvelle branche. simplement copier et coller le script groovy, adapter les branches et permettre à la graine de travail de créer de nouveaux emplois. Assurez-vous que les graines de travail supprime nonmanaged emplois. Ensuite, vous pouvez facilement échelle, avec des branches sur différents projets maven.

    Mais comme tom l'a dit ci-dessus, il serait plus agréable pour surmonter la nécessité de branches et d'enseigner les développeurs à intégrer proprement, mais c'est un processus plus long et le résultat n'est pas clair avec de nombreux système d'héritage des pièces que vous ne touchez plus.

    mes 2 cents

    InformationsquelleAutor prosailor