Comme dit le dicton ce n'est pas la destination, mais la route qui compte. On pourrait dire la même chose pour DevOps et de son implantation dans une organisation. Oui, le résultat est magique puisqu'il vise à nous faire livrer quotidiennement de la valeur d'affaires, mais le périple l'est d'autant plus. Ce périple est rempli de découvertes organisationnelles, technologies, mais surtout humaines.
Dans les dernières années, j’ai beaucoup accompagné d’entreprise qui débutait ou qui avait déjà amorcé leur transition vers l’agilité et la plupart de ces clients, sans le dire explicitement, voulaient mettre en place une pratique, voir, une culture DevOps dans leur organisation. Tandis que d’autres me posaient directement la question : Comment puis-je mettre en place la pratique DevOps ?
Dans tous les projets et compagnies, j’ai vu émerger un « pattern » qui est devenu, avec les années, un ordre d’implantation, pour mettre en place une pratique DevOps. Ce n’est certainement pas la seule approche, loin de là, mais c’est celle que j’ai vu fonctionner chez nombreux clients.
Voici ce que j’appel le DevOps Cake…
En expliquant ce "pattern" dans les dernières semaines, j’ai dessiné ce qui ressemble à un gâteau de mariage, donc voici la raison derrière son nom… Comme un gâteau, chaque étape se repose sur les étapes précédentes pour être solide et donner le meilleur des résultats.
Étape 1 – Intégration continue
Cette première étape est la fondation, voire la pierre angulaire, de tout ce qui va suivre par la suite. La raison pour lequel c’est la première c’est que généralement, l’implantation de l’agilité commence toujours au niveau d'une ou des équipes de développement et l’intégration continue est souvent la première chose qu’une équipe Scrum va mettre en place. L'intégration continue bouleversera que l’équipe Scrum et épargnera le reste de l’organisation donc fait de cette étape une option stratégique.
Durant cette étape, l’équipe sera forcée de concevoir et développer de manière à pouvoir s’intégrer sur une base quotidienne ou sinon complexifiera énormément leur travail et deviendra même un bloquant. Malheureusement, c’est à cette étape que plusieurs organisations resteront bloquées puisque la prochaine étape, la conception par les essais, est la première étape qui amènera des changements à l’extérieur de l’équipe.
Étape 2 – Test automatisé / conception par les essais
Cette deuxième étape est l’une de mes préférées pour plusieurs raisons. Premièrement, cette étape permet de valider si la conception et le développement suivent de bonnes pratiques agiles. Ensuite, elle permet de valider si l’organisation comprend et croit en l’agilité parce que l’étape précédente ne bousculait que l’équipe de développement tandis que celle-ci va élargir la portée des changements qu’elle apporte et ce à plusieurs niveaux :
- Cette étape bouleversera la gestion, habituée à une vélocité passée n’incluant pas le développement de tests automatisés, la nouvelle vélocité à la baisse de ou des équipes perturbera leur planification.
- Les tests d’acceptations automatisés vont bouleverser les gens affaires exemple: le responsable de produit. L’introduction de cette pratique, si l'on veut qu’elle soit un succès, forcera ceuxci à découper leurs récits (stories) d’une manière différente et penser en cas d’utilisation affaire. Ensuite, pour permettre à l’équipe de développement de bien concevoir les tests en amonts, les critères d’acceptations devront être bien définis pour le sprint planning.
C’est souvent lors de cette étape que Scrum en prend un coup et que les compromis débuteront pour ne pas bouleverser les façons de faire ou mettre les gens en situation d’inconfort, mais d’apprentissage. C’est pour cette raison que plusieurs organisations restent prises à cette étape ou même arrêtent complètement l’implantation des tests automatisés. En faisant ça, leur perception et compréhension de la pratique des tests automatisés reste teintée du coût en monté de compétence sans jamais bénéficier des résultats positifs de la pratique.
Cette étape est l’une de mes préférés parce que c’est souvent lors cette étape que le déclic se produit avec l’équipe de développement. C’est durant cette étape que l’équipe réalise la valeur réelle de l’intégration continue et les avantages d’avoir une bonne batterie de tests automatisés, tant unitaires que d’acceptation.
Étape 3 – Intégration des bases de données dans le développement itératif
Lorsque l’équipe Scrum a atteint un bon niveau de maturité avec les deux précédentes étapes et ça on peut l'observer quand durant les rétrospectives, l’équipe commence à identifier les bases de données comme étant un bloquant à livrer de la valeur affaires plus rapidement. C’est surtout vrai dans les organisations où la modélisation et les changements dans les bases de données peuvent être faits que par les DBA (administrateur de base de données). Une des raisons pourquoi cette problématique ne ressort pas plus tôt, c’est que les équipes de développement, lors des deux étapes précédentes, sont en montées de compétence ce qui permet au DBA de suivre la cadence des équipes Scrum tout en gardant leur façon de faire traditionnelle.
À part l’arrivé des bases de données NoSQL, le monde des bases de données n’a pas beaucoup évolué dans ses façons de faire comparativement au aux autres sphères du développement logiciel, c’est pourquoi cette étape va apporter différents défis pour les DBA :
- Avec la cadence des sprints, les équipes de développement ne pourront pas toujours prévoir plusieurs semaines voir plusieurs jours d’avance les modifications aux modèles de données. Ce qui fera que les DBA seront surchargés de demandes en début de sprint et cette surcharge deviendra un bloquant pour les équipes de développement. Il est donc essentiel que les équipes de développement soient autonomes à faire des modifications au schéma de la base de données puisque prévoir plusieurs sprints d'avance les changements n'est pas la solution. Une piste de solution, est d'ajouter un élément à la définition de terminer pour qu’un DBA regard les modifications au schéma, un peu comme le code review.
- Puisque les changements de base de données peuvent être faits par tout membre de l’équipe de développement, ces changements doivent suivre les mêmes règles que le reste du code: être automatisé, versionné et fusionné quotidiennement.
Donc, leur demander du jour au lendemain de changer leur façon de faire leur travail et souvent les outils pour être en mesure de suivre la cadence des équipes Scrum peut être insécurisant. Je crois qu’ils ont tout à gagner de faire le changement pour faire pleinement bénéficiers l’organisation de leur connaissance plutôt que d’être responsable de concevoir et d’exécuter des scripts SQL. Cette étape est cruciale pour la prochaine si on veut être en mesure d’automatiser l’ensemble du processus de déploiement pour y inclure les bases de données.
Étape 4 – Livraison continue
La prochaine étape pour une équipe Scrum et une organisation qui vise à implanter DevOps est l’automatisation des déploiements. Habituellement, cette étape fait son apparition quand l'équipe ou les équipes atteignent un niveau de maturité avec les étapes précédentes et veulent inclurent le déploiement dans leur processus de livraison de valeur ou définition de terminer.
Après l'introduction des DBA avec l'étape précédente, ce coup-ci on introduit l'équipe d'infrastructure au sens large. Un peu comme les équipes de DBA, l'équipe d'infrastructure doit changer leur manière de travailler, ce qui implique de donner plus de latitude aux équipes de développement. Ce que je veux dire par là, c'est que les équipes d'infrastructure, les Ops, doivent définir les recettes ou contenant, mais laisser libre aux équipes de développement, les Devs, d'y mettre ce qu'ils veulent. Pour ainsi avoir une infrastructure qui répond à leur besoin et non un "one size fit all" de l'infrastructure qu'on voit typiquement dans les organisations.
Cette étape n'est souvent pas un défi technique, mais plus organisationnel, à part la courbe d'apprentissage des outils de déploiement automatisé, puisqu’habituellement comme dans la plupart des organisations, il y a un historique entre les Dev et les Ops. C'est pour cette raison que c’est à cette étape qu'on voit apparaître les dysfonctions qui seront les futurs défis à l'implantation de DevOps dans une organisation.
L'équipe d'infrastructure (incluant les gestionnaires) ne doit plus voir les infrastructures comme leurs propriétés, mais plutôt comme un vecteur permettant aux équipes de développement de livrer plus rapidement de la valeur d'affaires. Étant responsable du contenant et non du contenu, il est impératif que les équipes Ops changent leur manière de voir les choses, pour ainsi respecter autant leurs objectifs que ceux de l'équipe de développement. À cette étape, habituellement, l'infrastructure de chacun des paliers (dev. pré-production et production) sera créée manuellement, mais les déploiements seront automatisés. Ce qui amènera, dans certains cas, à des inconsistances au niveau des paliers, mais surtout une pression énorme sur l'équipe Ops qui, par l'approche manuelle, aura du mal à suivre la cadence des équipes Scrum ou Kanban. Malheureusement pour passer à la prochaine étape, un peu comme les DBA, c’est la pression ou le désir d’apprendre et s’améliorer qui fera en sorte que les Ops se dirigeront vers l’automatisation de la création de l’ensemble de l’infrastructure.
Étape 5 – "Infrastructure as code"
Cette étape est la dernière, et c’est l’étape où la technologie sera la solution pour diminuer la pression sur une équipe, celle des Ops et du même coup accélérer le cycle de livraison des Devs. Comme je disais plus tôt, avant d'arriver à cette étape, il faut que l'organisation ainsi que les Ops perçoivent que les anciennes façons de faire, qui ne sont pas mal en soit, mais mal adaptées pour suivre la cadence qu'apporte l'agilité. Typiquement, lors de cette étape les Devs et les Ops de l'organisation, vont ensemble mettre en place les outils et les techniques pour respecter la mission de chacun qui, comme je l’ai dit dans un autre billet, va à l'opposée de l'une de l'autre. Et c'est seulement qu'après, qu'une pratique DevOps pourra être mise en place dans l’ensemble de l’organisation. Ces outils et méthodes vont permettre aux Ops de produirent des recettes technologiques automatisées, qu'ils rendront disponibles aux équipes de développement. Ainsi, l'infrastructure sera immuable et définis dans son ensemble par les Ops tout en permettant au Devs de les utiliser et d'y déployer les incréments logiciels priorisés selon la valeur affaires.
Et après c'est fini ?
Les organisations, dans leur aventure vers DevOps ou juste vers l'amélioration de l'implantation de l'agilité, suivent habituellement ce cycle et comme on voit, il y a plusieurs étapes avant d'y arriver. Et chaque fois, c'est quand les personnes deviennent matures avec tout ce que comporte l’étape courante qu’ils seront poussés à passer à la prochaine. C'est pour cette raison que je dis souvent qu'on ne peut pas être agile, c’est plutôt un idéal vers lequel il faut tendre puisqu'il y a toujours quelque chose qu'on peut améliorer, que ça soit nous ou nos façons de faire.
J'en ai pas parlé explicitement mais c'est toujours le cadre de travail agile, comme Scrum ou Kanban, qui stimule l'amélioration continue nécessaire à une culture DevOps. Quand on regarde attentivement l'enchaînement des étapes, on peut y déceler 3 éléments fortement liés ensemble soit, le processus agile, les outils et les personnes. Et à la base c'est cette boucle continue qui permet de passer les 5 étapes et du même coup obtenir des gains pour l'ensemble de l'organisation.
Quand on atteint la dernière étape ce n'est pas terminé, loin de là !
Le défi est maintenant de diminuer le temps de cycle de l'ensemble de l'organisation. Ce que je veux dire par là, c'est de diminuer le temps entre l'émergence d'une idée ou l’identification d’un nouveau besoin jusqu'à son déploiement en production. Et cela devient possible en inspectant et adaptant de manière continue notre processus de production de valeur avec l’aide d’un cadre de travail agile tel que Scrum ou Kanban.
Comme je disais au début de mon billet, l’implantation de DevOps est un périple de découverte, de découverte de dysfonction dans l’ensemble de l’organisation. Ça peut sonner négatif, mais c’est loin de l’être puisque ces dysfonctions ne sont que des opportunités d’apprentissage et d’amélioration pour l’organisation et du même coup pour les personnes impliquées. Ensuite c’est la capacité d’une organisation à s’inspecter et s’adapter qui permet de ne pas rester coincée à une étape et ainsi ne pas atteindre le plein potentiel de l’implantation de DevOps ou même de l'agilité.
Dans mon prochain billet je parlerai plus du volet technologique et technique de chacune des étapes, bon voyage !