Après avoir passé 2 bonnes heures à expliquer à sa tante l’intérêt du « feature branching« , Léo continue sa réunion familiale et enchaîne avec son oncle.
Tonton, nous on est pas oklm, on est des vrais badasses du dev. On s’enjaille même à faire de la mise en prod en continue.
Bon, comme la dernière fois, je ne peux rien pour toi concernant le vocabulaire 2020 mais on va creuser la technique.
Alors, c’est quoi l’intégration continue ?
L’objectif est simple, intégrer en continue les changements/modifications de code apporté(e)s à un projet. Si vous avez suivi mon précédent article vous avez compris que les développeurs peuvent travailler sur des branches et que la difficulté est le regroupement de ces branches.
Et bien, l’intégration continue cherche à résoudre les problèmes d’intégration en obligeant les développeurs à regrouper, sur une branche commune, leurs développements tous les jours.
Ceci fait apparaître une notion TRÈS importante qui est le test automatique et continue. Hé oui! avec cette méthode il faut être « blindé » sur les tests de non régression afin d’assurer en permanence un environnement sans faille.
Le schéma ci-dessous vous présente de manière très visuelle le déroulement d’une intégration continue.
L’avantage, qui selon moi, est le plus important est la réduction du risque liée à l’intégration.
Il est important de comprendre que :
« Tout risque GRANDI avec le temps. »
Et c’est particulièrement vrai avec les projets informatiques.
Plus un projet informatique est long :
- Plus le temps de test sera long
- Plus le projet sera complexe à appréhender
- Plus la formation des équipes sera longue
- Plus la mise en production risque d’être longue et avoir des impacts collatéraux
- Plus vous générez d’attentes et plus vous risquez de décevoir
- …
Les autres avantages, de cette méthode de mise en production, vont être :
- L’augmentation du niveau de confiance entre les développeurs.
- La généralisation de tests de non régression.
- L’amélioration de la qualité du code.
Ok, mais pourquoi je vous parle de ça ?
Et bien, après avoir essayé de vous expliquer (avec le précédent article) que les développeurs étaient TRÈS sensibles aux besoins fonctionnels et étaient plus efficaces s’ils développaient de petits éléments fréquemment…
mon objectif est de vous faire réfléchir au coût de la mise en production dans votre organisation.
Selon moi, plus ce coût est élevé et :
- Moins vous êtes agile.
- Plus vous cumulez des risques sur peu de personnes.
- Moins vos équipes IT sont autonomes.
Si je devais le matérialiser sur un graphique voici ce que ça donnerait (j’ai modélisé le coût avec des jours; ce ne sont pas des données réelles mais l’objectif est de vous donner une idée des impacts et des interactions entre les éléments).
Si vous voulez aller plus loin vous pouvez réaliser le test suivant :
Allez voir un de vos développeurs et demandez-lui d’ajouter « hello ceci est un test » en commentaire n’importe où dans une partie du code.
Mesurez ensuite le temps nécessaire à l’organisation pour que ce commentaire soit en production.
Vous aurez ainsi une idée plus précise du coût de mise en production dans votre organisation et des différentes barrières qui existent.
Une fois ce test passé, posez-vous aussi la question du coût des risques des projets que vous avez en cours.
Et n’oubliez pas :
Un geek énervé ne crie pas. Il URL !
Si cet article vous a plu, vous pouvez continuer avec, #InsideDevsBrain le fonctionnement du « Feature branching »
Ping : #InsideDevsBrain le fonctionnement du "Feature branching" - David LANGLADE