Les sept pratiques qui confirment votre niveau d’intégration continue

Par :
Brian Dawson

lun, 07/05/2018 - 15:57

Lors du Jenkins World 2017, j’ai particulièrement apprécié le moment où Jez Humble, figure phare de la sphère technologique, a fait lever les mains dans la salle pour savoir qui mettait en place une véritable intégration continue (IC). Les participants comptaient parmi les professionnels du DevOps les plus impliqués qui soient, et l’intégration continue était donc a priori un sujet sur lequel tout le monde était à la page.

 

Jez Humble a ainsi posé plusieurs questions : Créez-vous des builds réguliers pour alimenter le pipeline principal de votre organisation ? Êtes-vous en mesure de résoudre un problème de logiciel en moins de 10 minutes ? Que ceux qui répondraient par la négative baissent la main. Plusieurs bras se baissaient à chaque question, si bien qu’à la fin, la quantité de mains encore levées ne représentait qu’une infime fraction du nombre initial.

 

Le message était clair : Une grande proportion des gens pense appliquer des processus d’intégration continue alors que ce n’est pas le cas.

 

« L’intégration continue est un concept extrêmement compliqué, a expliqué Jez Humble, et beaucoup en donnent une définition toute personnelle qui ne fait que refléter les processus qu’ils ont déjà mis en place ».

Et vous, opérez-vous réellement une intégration continue ? La question est importante. Le déploiement continuet le DevOps sont des innovations disruptivesqui représentent un incroyable avantage compétitif sur le marché. Or, il ne peut y avoir de déploiement continu sans véritable intégration continue. Ainsi, de nombreuses entreprises ne comprennent pas réellement les avantages de la première, faute de bien saisir les concepts de la seconde.

Les entreprises qui réalisent une véritable intégration continue suivent toutes quelques règles de base. Les copies de travail des développeurs sont synchronisées avec une branche commune au moins quotidiennement, mais de préférence plusieurs fois par jour, et chaque intégration est vérifiée par un build automatique afin de détecter les erreurs aussi vite que possible. Les entreprises qui n’appliquent pas ces pratiques ne réalisent pas l’intégration continue de manière adéquate.

L’intégration continue est un ensemble de pratiques destinées aux équipes de développement, mais qui présentent de réels avantages pour l’entreprise toute entière. Les ingénieurs chargés de sa mise en œuvre ne demandent pas mieux que d’emboîter le pas à leurs homologues les plus avancés pour bénéficier de ces avantages. Ils se heurtent simplement à plusieurs problèmes en chemin.

Ils entendent des histoires sur la façon dont les autres organisations mettent en œuvre l’intégration continue, et tâchent ensuite de déterminer s’ils peuvent appliquer la même formule chez eux. Hélas, toutes les entreprises sont différentes. Les équipes DevOps peuvent avoir une certaine vision de ce à quoi l’intégration continue doit ressembler dans leur organisation, et il se peut que cette vision ne coïncide pas parfaitement avec la définition généralement acceptée de l’IC.

Les entreprises qui ne suivent pas les principes essentiels de l’intégration continue ont toutes les chances de se heurter à des difficultés pour créer des builds fonctionnels et de qualité de façon régulière. Au fil du temps, leurs initiatives perdront de l’élan et l’équipe son enthousiasme. Et si le changement ne semble pas porter ses fruits, ne serait-ce que progressivement, les gens réfractaires à la nouveauté (c’est-à-dire la plupart d’entre nous) reviendront à leurs anciennes pratiques. À ce stade, l’horizon n’est que problèmes : vos builds sont toujours truffés d’erreurs, votre équipe ne croit plus en l’initiative, vous avez perdu un temps précieux et vous devez maintenant recommencer votre projet du début.

Les entreprises qui implémentent l’intégration continue de façon incorrecte font souvent face à un problème d’ordre culturel. Les ingénieurs sont excellents pour résoudre les problèmes techniques, mais l’intégration continue demande un changement de culture, ce qui n’est pas chose facile. Vous pouvez investir dans un outil d’intégration et cocher la plupart des cases de votre checklist « Intégration continue », mais pour réussir, vous devez changer la façon dont vous travaillez, et notamment la façon dont vous travaillez ensemble.  Sans un changement de culture, votre équipe aura toutes les peines à mettre en œuvre une intégration continue.

En résumé, l’intégration continue est comme un imperméable que vous enfileriez par-dessus votre plus beau costume. Vous vous êtes engagé à respecter des délais de livraison extrêmement soutenus et à produire des versions toujours plus incroyables de la nouvelle application de votre entreprise, car vous êtes certain que votre imperméable (les principes d’intégration continue) protégera votre projet. Mais si cet imperméable ne l’est pas réellement (imperméable), votre costume sera bon à jeter, et il en va de même avec l’IC. Si vous l’exposez aux éléments, votre projet risque fort de prendre l’eau.

Mais attention : n’allez pas en déduire que les processus d’IC visent à éliminer les erreurs. L’intégration continue est, bien au contraire, un concept qui accorde une place prépondérante à l’échec. Nous cherchons à créer un système qui autorise les développeurs à se tromper souvent et surtout rapidement, afin que les erreurs soient résolues le plus tôt et le plus vite possible. L’intégration continue est comme une barrière le long d’une route sinueuse : elle donne aux développeurs la confiance nécessaire pour conduire à toute allure, car ils savent qu’ils sont protégés si leurs builds s’approchent trop du bord dans un virage.

Les principes et pratiques de base de l’intégration continue remontent à au moins 15 ans, quand Martin Fowler avait inventé le terme, et s’appliquent de la même façon aujourd’hui comme hier. Voici une liste un peu plus détaillée des pratiques que les entreprises doivent mettre en place pour la mettre en place dans les règles de l’art :.

  1. Alimentez la branche maître : il s’agit d’un principe fondamental de l’intégration continue. Un développeur peut créer un build automatique qui sera exécuté à chaque soumission, mais si la culture de l’équipe est de ne pas faire de soumissions fréquentes dans la branche maître, cela ne servira à rien. Si un développeur attend trois semaines pour soumettre son build ou travaille sur une branche à part pendant la même période, il retarde l’intégration et ne respecte pas les principes d’IC. Si le build ne fonctionne pas, l’équipe devra revenir sur trois semaines de travail pour trouver d’où vient l’erreur.
  2. Utilisez un référentiel à source unique : dans les applications complexes, les développeurs créent souvent des branches secondaires qui s’écartent de la branche maître, dans lesquelles ils gèrent les modifications. Ces ramifications compliquent le processus et ne permettent pas de travailler avec une seule et même source de référence. Les équipes doivent soumettre (fusionner) leur travail dans la branche maître au moins une fois par jour ou, idéalement, à chaque modification.
  3. Automatisez le build : il s’agit de la pratique que les entreprises appliquent généralement le mieux. Cependant, certaines organisations se contentent de livrer des builds à intervalles réguliers (par exemple, chaque nuit), ou encore créent des builds en continu, mais sans réellement les tester ni les valider un par un. Sans validation du build, vous ne faites pas une intégration continue.
  4. Créez des builds capables de se tester automatiquement : la première étape du processus de validation est de savoir qu’un build comportant des problèmes a rencontré une erreur. L’étape suivante est de déterminer si le produit du build est opérationnel et fonctionne comme prévu. Ces tests doivent être intégrés au processus de création de builds. Il s’agit de tests de fonctionnalité rapides.
  5. Travaillez rapidement : si la création d’une application prend trop de temps, les développeurs seront moins enclins à apporter des modifications régulières ou les ensembles de modifications seront plus importants. Dans un cas comme dans l’autre, il sera impossible de repérer les erreurs rapidement. Une création et une intégration rapides vous permettent d’isoler les problèmes de façon tout aussi rapide. Si l’exécution prend des heures, vous risquez de vous retrouver avec 20 ou 30 autres modifications sur les bras dans l’intervalle, et les problèmes n’en seront que plus difficiles à repérer.
  6. Effectuez des tests dans un clone : la validation sert à vérifier que le logiciel fonctionne normalement dans l’environnement pour lequel il est prévu. Si vous le testez dans un autre type d’environnement, vos résultats peuvent être erronés.
  7. Réparez les builds défectueux immédiatement : il est essentiel de détecter les problèmes rapidement et de les corriger immédiatement, afin qu’ils n’aient pas de répercussions plus en aval. Il y a quelques années, Toyota avait mis place l’approche « stop-the-line » (arrêt de la chaîne), qui permettait aux ouvriers d’arrêter le processus de fabrication s’ils repéraient un problème. Dans un système d’IC, les builds sont validés et soumis en permanence, ce qui facilite la résolution des problèmes.

Malgré toutes les difficultés rencontrées par les organisations pour mettre en place une véritable intégration continue, il est important de saluer l’ampleur des efforts réalisés par la communauté des développeurs pour adopter des processus modernes qui améliorent leurs opérations. Beaucoup d’entre eux font tout leur possible pour faire bouger les choses et améliorer leurs pratiques de DevOps. Le principal obstacle à l’IC est notre attachement culturel, sentimental et techniques aux anciennes technologies, un attachement qui fait résistance au changement. Même si vous parvenez à vous débarrasser de votre « culture de l’impossible », vos anciennes pratiques peuvent vous tirer en arrière.

L’autre difficulté rencontrée par les entreprises est qu’elles présument souvent de leurs capacités. Tout le monde veut transformer ses opérations à l’aide de méthodologies telles que l’IC, mais beaucoup d’organisations en profitent pour fermer les yeux sur les modifications qu’elles doivent encore apporter à leurs processus. Plus de dix ans après l’apparition du terme d’intégration continue, nous avons encore toutes les peines à appliquer ce concept correctement.

A propos de l'auteur

Brian Dawson
DevOps Evangelist chez CloudBees