Garder votre système d'intégration continue

Un de mes rôles dans mon équipe est la personne de construction . Je suis responsable de la maintenance / mise à jour de nos scripts de construction et de m'assurer que nous construisons «en douceur» sur le serveur d'intégration continue. Cela ne me dérange généralement pas de faire ce travail, même si souvent j'ai l'impression de garder constamment le serveur CI.

Ce travail peut parfois être ennuyeux parce que si la construction se brise, je dois abandonner l'histoire sur laquelle je travaille et enquêter sur l'échec de la construction. Les échecs de build se produisent quotidiennement dans notre équipe. Parfois, les développeurs ne construisent tout simplement pas localement avant de s'engager, les tests échouent donc sur le serveur CI. Dans cette situation, j'aime arriver rapidement à la personne qui a eu le «mauvais commit» afin que le build ne reste pas trop longtemps cassé. Parfois (beaucoup moins fréquemment) une condition étrange existe sur le serveur CI qui doit être déboguée.

Je sais que de nombreuses équipes matures utilisent l'intégration continue, mais il n'y a pas beaucoup d'informations sur les bonnes pratiques.

Mes problèmes indiquent-ils que notre intégration continue n'est pas très mûre ou cela fait-il simplement partie du travail?

Quelles sont les bonnes pratiques à suivre? Quelles sont les caractéristiques d' une intégration continue mature ?

Mise à jour

Au lieu de répondre à certains commentaires, je vais plutôt faire une mise à jour. Nous avons une seule commande simple qui fait exactement ce que le serveur de build fera lors de la construction de l'application. Il compilera, exécutera toutes les unités / l'intégration et quelques tests rapides basés sur l'interface utilisateur.

En lisant les réponses de chacun, on sent que nous pourrions avoir deux problèmes majeurs.

1. CI Server ne se plaint pas assez fort quand une construction échoue.
2. Les développeurs ne se sentent pas responsables de la responsabilité de chacun de s'assurer que leur engagement se déroule correctement.

Ce qui rend les choses plus difficiles dans mon équipe, c'est que nous avons une grande équipe (plus de 10 développeurs) ET nous avons quelques membres de l'équipe offshore qui s'engagent lorsque nous ne sommes même pas au travail. Parce que l'équipe est grande et que nous avons établi que les petits et fréquents commits sont préférés, nous avons parfois vraiment beaucoup d'activité en une journée.

D'abord et avant tout: chaque personne est responsable du processus de construction . Il semble que les membres de votre équipe ne soient pas matures ... Personne ne s'en sort en écrivant du code et en le transmettant au serveur CI en espérant que cela fonctionne. Avant de valider le code, il doit être testé sur sa machine locale. Vous devez être sûr que le code que vous archivez ne cassera pas la construction. Bien sûr, il y a des cas où la construction s'arrête involontairement (par exemple si un fichier de configuration a été modifié ou si une validation bâclée a été effectuée par inadvertance).

La plupart des serveurs CI (je n'ai utilisé que Hudson) enverront un e-mail automatisé détaillant les commits effectués qui ont causé la rupture de la version. La seule partie de votre rôle est de les soutenir durement jusqu'à ce que le suspect répare tout ce qu'il a cassé.

Votre équipe s'est trompée:

Être responsable du serveur de build n'est pas la même chose qu'être responsable de la build .

Il incombe à la personne qui vérifie le code de le faire "fonctionner" (pour une certaine valeur de travail). La seule raison d'avoir un serveur de build est d'attraper des oublis dans ce processus. Tout serveur de build digne de ce nom peut notifier les personnes qui ont archivé le code depuis la dernière build (ainsi que toute autre personne intéressée) avec les informations suivantes:

• La construction s'est cassée!
• Qu'est-ce qui a mal tourné lors de la construction!
• Ce qui a changé depuis la dernière version!

Cela se produit très fréquemment par e-mail. Il est important que cela se produise assez rapidement après chaque enregistrement.

La personne peut alors voir ce qui s'est mal passé et le corriger, et le serveur de build informe ensuite toute personne intéressée que la build est revenue à la normale. Cela devrait se produire tout seul sans aucune implication des autres, mais des coupables d'enregistrement.

Donc, pour répondre à votre question: Un environnement CI mature ne nécessite PAS la participation d'un concierge dans son fonctionnement normal.

De plus, si des «conditions étranges existent» se produisent très fréquemment, recherchez la cause et rendez le système plus robuste.

Modifiez le processus. Si une validation rompt la génération, annulez automatiquement cette validation et informez le développeur qui l'a rompue. Il est stupide de permettre à un membre de l'équipe de ralentir le reste de l'équipe. Ou au lieu d'avoir des builds d'intégration effectués automatiquement, demandez aux développeurs de vérifier la machine d'intégration, et si la build réussit, ils peuvent alors valider. L'intégration continue ne signifie pas «archivez les fichiers indésirables que vous aimez et quelqu'un les réparera pour vous».

La stratégie de "branche d'or" ne fonctionne pas à moins qu'il n'y ait un gardien pour la branche d'or.

Un DVCS comme Git pourrait aider; au lieu de valider, le développeur peut simplement soumettre un ensemble de modifications pour intégration au serveur CI, et le serveur peut alors tenter d'intégrer l'ensemble de modifications. Si l'intégration réussit, l'ensemble de modifications est fusionné et sinon, il est rejeté.

Un problème que je vois souvent est que les développeurs ne peuvent pas effectuer une build locale qui a exactement les mêmes étapes qu'une build CI. Autrement dit, le serveur CI est configuré pour inclure des étapes supplémentaires telles que les tests unitaires / d'intégration, la couverture, etc. qui ne peuvent pas être effectuées localement. Inévitablement, les développeurs seront mordus par l'une des étapes qu'ils ne peuvent pas effectuer localement et commenceront à se demander pourquoi ils se donnent la peine de créer une version locale avant de s'enregistrer.

Je garde ma version complète autonome et je demande au serveur CI de lancer simplement une version sans aucune configuration / étape étrangère définie. Les développeurs peuvent exécuter une version release localement avant l' enregistrement qui comprend toutes les étapes qui seront effectuées par la construction de CI et beaucoup plus confiants que rien ne se brisera quand ils font le check-in.

Les avantages supplémentaires de cette approche incluent:

• il est facile de basculer entre les serveurs CI car vous n'avez pas investi beaucoup de temps à configurer des étapes étrangères
• tous les outils de construction sont sous contrôle de source, ce qui signifie que tous les développeurs utilisent exactement le même ensemble d'outils pour construire votre système
• en plus du point ci-dessus, il est simple de modifier l'outillage de construction de manière contrôlée

PS. le concept de garde d'enfants dans son ensemble est ridicule, mais d'autres l'ont couvert.

Tout d'abord, les développeurs ne doivent pas interrompre régulièrement les builds - ils doivent créer et exécuter les tests localement avant de s'engager dans la branche CI. Cela devrait être une honte de rompre la construction, et il est important de l'imposer. Je l'ai fait en publiant des statistiques, et j'ai vu d'autres équipes avoir un "sac de construction" où vous mettez un dollar chaque fois que vous interrompez la construction. À la fin du projet, cet argent va à la bière.

Si la honte / fierté personnelle ne fonctionne pas, vous devrez peut-être passer à des choses plus lourdes (par exemple, menacer de mettre fin à votre contrat). Briser la construction avant de partir pour la journée devrait être une infraction majeure. Et chaque développeur devrait avoir une notification d'état de build sur son bureau. La meilleure partie de tout cela est qu'il encourage les petits commits, qui sont de toute façon préférés.

Cela dit, la build se casse parfois (raisons de configuration CI, par exemple). Et parfois, les gens vont bousiller et partir pour la journée avec la construction cassée. C'est pourquoi vous devriez viser un processus qui permet de revenir rapidement et facilement aux bonnes versions connues. Si vous pouvez toujours revenir à la dernière bonne version (et que la version restaurée soit déployée à tous les endroits nécessaires), alors dans le pire des cas d'une construction cassée où le coupable est parti pour la soirée, vous pouvez rouler revenir à la dernière bonne version et crier après lui le matin.

Je ne peux pas recommander assez le livre de livraison continue . Si vous cherchez un guide sur la façon de faire mûrir votre processus CI, essayez-le.

J'ai entendu parler d'une chose que fait Microsoft (peut-être?), Qui est de faire en sorte que la fonction de baby-sitter se déplace dans l'équipe. La façon dont ils le font est que lorsque quelqu'un casse la construction (qui devrait probablement inclure l'enregistrement de quelque chose qui échoue à ses tests), il assume le rôle. Cela rend les gens responsables des conséquences de leurs actions de manière très directe. Et étant donné que c'est un travail quelque peu ennuyeux à faire, cela les encourage à ne plus casser la version.

La personne qui est actuellement responsable de la construction pourrait avoir un chapeau spécial. Il pourrait y avoir une cérémonie pour le remettre.

Notez que, comme le dit Thorbjørn, être responsable de la génération n'est pas la même chose que d'être responsable du serveur de génération. La responsabilité du serveur pourrait incomber en permanence à un ou plusieurs membres de l'équipe enclins aux infrastructures tandis que la responsabilité de la construction se déplace.

Maintenant, mis à part les détails du processus, je vais rejoindre le chœur de personnes exprimant leur consternation face aux développeurs qui s'enregistrent sans avoir exécuté de build et de test. Inacceptable!

Si vous avez des membres de l'équipe qui sont plus susceptibles de casser la construction (et d'après ma propre expérience, je pense principalement aux membres d'un autre pays), et si vous utilisez un bon contrôle de source moderne comme Mercurial ou Git, vous pouvez leur demander de se connecter à une autre branche du reste de l'équipe, d'exécuter un processus CI distinct sur celui-ci et de fusionner automatiquement les modifications de cette branche dans le tronc après une construction réussie (notez que vous devrez exécutez une deuxième génération et testez après la fusion avant de vérifier la fusion!). Étant donné que la fusion automatique n'est pas toujours réussie, cela finirait par laisser la branche nécessitant une attention manuelle, ce qui pourrait être une vraie douleur. Cela pourrait être moins douloureux que d'avoir un code cassé enregistré pour le reste de l'équipe.

Comme Jonathan Khoo l'a dit, vous devriez tous être responsables du serveur de build et du script de build. Il y a trois raisons:

1. Pour le moment, vous avez un cas de "Bus de 1", ce qui signifie que si vous êtes écrasé par un bus, toute la connaissance du serveur de construction et des scripts de construction est perdue.
2. Les scripts que vous avez écrits (à tort ou à raison) n'ont reçu que votre contribution. Comme tout code, plus il y a de personnes impliquées, plus la base de connaissances qui peut lui être appliquée est large.
3. Enfin, lorsque quelque chose se passe mal, vous seul ressentez la douleur. La douleur est une bonne chose, mais pas lorsqu'elle est isolée. Pour le moment, vous faites face à la douleur, mais si tout le monde éprouvait de la douleur, vous découvririez qu'ils seraient éventuellement plus stricts dans le test du code avant de vous engager.

Je suis très impliqué avec CI moi-même et je tombe dans le piège d'être celui qui gère les scripts, mais voici quelques choses que vous pouvez faire pour atténuer cela.

1. Les scripts de construction ne doivent pas uniquement s'exécuter sur les serveurs CI mais également sur les machines de développement locales. Ils doivent produire les mêmes sorties, exécuter les mêmes tests et échouer pour les mêmes raisons. Cela permet aux développeurs d'exécuter le script avant de valider leur code.
2. Si quelqu'un casse la version, rendez-la publique via l'utilisation de fenêtres contextuelles, d'e-mails, de lumières clignotantes, de bruits, etc. aider.
3. Pendant un certain temps, évitez de corriger la construction. Demandez à quelqu'un d'autre de le faire. Si personne d'autre ne saute, attendez que de mauvaises choses se produisent et utilisez-le comme point d'apprentissage pour que toute l'équipe comprenne pourquoi le serveur CI est important.
4. Essayez de garder votre serveur de build et vos machines de développement aussi dépourvus de composants tiers installés que possible, en particulier gardez le GAC propre. Comptez sur les composants tiers qui se trouvent dans le dossier de la bibliothèque de projets. Cela permet d'identifier plus rapidement les composants manquants.

La visibilité vous aidera. Tous les membres de l'équipe doivent savoir qu'il existe un problème actif qu'ils doivent résoudre. Les notifications par e-mail sont utiles, mais si un développeur est occupé et ne réagit pas immédiatement, il l'oubliera probablement et l'e-mail se retrouvera dans une énorme pile de notifications.

Vous pouvez essayer d'utiliser des outils comme Catlight ou BuildNotify . Ils montrent l'état actuel des builds importants dans la zone de plateau. Chaque fois que le développeur regarde l'horloge, il voit qu'il y a une version cassée qui doit être réparée.

Catlight montrera également qui a rompu la construction en premier, mettant une pression sociale sur cette personne, comme toute l'équipe le verra à chaque échec de construction consécutif.

Une stratégie consiste à utiliser de nombreuses petites succursales pour de nombreux petits projets. Ensuite, lorsque quelqu'un casse la version, il ne fait que la casser pour lui-même. Ils reçoivent donc les e-mails ennuyés du serveur de build et c'est à eux de s'en inquiéter.

Une autre consiste à améliorer le niveau de responsabilité des personnes. Par exemple, si vous utilisez quelque chose comme Rietveld, les gens ne peuvent pas s'engager sans passer un examen par les pairs. (Le processus dans la pratique est beaucoup plus léger que vous ne le pensez. Mais il oblige les gens à "canaliser" et à travailler sur plusieurs choses à la fois.) La préservation de la construction est à la fois la responsabilité du validateur et des réviseurs. Si quelqu'un casse régulièrement la version ou approuve des éléments qui la cassent, ne les laissez pas donner les approbations finales pour les validations. Combinez avec un processus où n'importe qui peut facilement annuler toute modification, et la construction ne se cassera pas aussi souvent et ne restera pas interrompue une fois la modification effectuée.

Je vais rompre avec le refrain ici, et dire qu'en fait, rompre la compilation de temps en temps n'est pas une si mauvaise chose, car cela montre que le travail est en cours. Oui, les développeurs doivent construire et tester avant de s'engager, mais le principal fardeau des tests devrait être supporté par les outils d'automatisation du développement, y compris le serveur d'intégration continue. Les outils sont là pour être utilisés, et à moins que la construction ne se brise de temps en temps, il n'est pas clair que vous poussiez aussi fort que vous le pouviez. Cependant, je pense que la version ne devrait jamais rester interrompue pendant une période de temps significative, et serait même favorable à des restaurations automatiques ou à un processus de validation en plusieurs étapes si cela aide à soutenir le double objectif de rétroaction rapide des installations de test centralisées et automatisées, plus un coffre "vert".

Couples choses à garder à l'esprit:

1. Votre équipe a besoin d'un ensemble de normes à suivre
2. Vous devez intégrer la gestion avec l'idée d'un code propre et vous efforcer d'améliorer les pratiques de code.
3. Test test test! Testez toujours avant de vous enregistrer.
4. Bien que je convienne qu'il est correct de casser la construction, c'est une occasion rare et je veux dire extrêmement rare qui serait acceptable. Si c'est tous les jours, je chercherais la porte ou parlerais à mon patron des normes.

Dans l'ensemble, vous devez définir, rédiger des normes basées sur les meilleures pratiques et non sur vos pratiques individuellement (évidemment, cela ne fonctionne pas). Une fois que tout le monde est d'accord sur les normes, commencez le processus de révision du code et l'application des normes. On dirait presque que la direction est partie en vacances et n'est jamais revenue. Ce sont des choses qui sont honnêtement assez basiques pour n'importe quel magasin. la base d'un bon code commence par de bonnes normes pour dicter le code des équipes et comment il est écrit. Juste mes pensées. Je suis récemment entré dans une situation similaire à mon nouvel emploi et j'ai parlé à mon patron. Nous lui avons expliqué que nous avons besoin de terminer XYZ car cela affecte ABC. Deux semaines plus tard, j'ai écrit une liste de normes de code à suivre et je l'ai présentée. Suivi par mes collègues qui y ont donné leur avis et environ 2 mois plus tard, nous avons mis en place des normes qui ont résolu des tonnes de problèmes.