On parle beaucoup de DevOps ces temps-ci. Mais est-ce qu’on saisit bien toute sa définition et les impacts de son implantation au sein d’un organisme ou une entreprise? Commençons par bien définir le DevOps pour avoir une meilleure perspective que le simple « buzzword ».
Au premier abord, on peut penser que faire du DevOps, c’est tout simplement une histoire d’outils:
Euh, mais non. Bien que certains outils soient nécessaires pour automatiser les aspects de notre livraison en continu, il y a bien plus que cela en jeu. Le fait de choisir des outils, de les l’installer, de les configurer et de s’en servir ne veut pas nécessairement dire qu’on fait du DevOps. Donc:
Poursuivons notre analyse. Si les outils ne règlent pas tout, j’imagine qu’il faut y mettre un peu de collaboration. La collaboration usuelle à laquelle on pourrait facilement penser est bien sûr la suivante:
Tout à fait d’accord avec ceci! D’ailleurs, il faut faire attention si on travaille actuellement en silos (développement et opération) de ne pas répéter la même chose avec DevOps en la mettant elle aussi dans un silo. On n’a pas besoin d’une troisième équipe qui fonctionne ainsi, n’est-ce pas? On a besoin davantage d’unir les forces de l’équipe de développement et de celles des opérations (environnement, sécurité, livraisons, mise en production, etc) afin de plutôt en faire une équipe qui s’entraide mutuellement. Bref, on veut que tout le monde se préoccupe des livraisons en production.
Par contre, déplaisant et poser ma question de coach:
C’est bon, vous voulez livrer en continu, mais pourquoi? Cela donne de la valeur à qui en bout de compte?
Oups, il nous manque une partie importante dans notre équation! Donc:
La partie affaires (utilisateurs, pilotage, PO, analyste d’affaires) doit aussi être incluse dans notre équation DevOps, ce qui équivaut à représenter le DevOps ainsi:
Il manque ainsi une bonne partie de l’équation si on fait du DevOps sans se préoccuper du côté affaires, avec des éléments tels que:
Les affaires, le développement et les opérations ont tous à la base des objectifs différents:
- Développement: livraison d’incrément du produit;
- Opérations: stabilité, fiabilité et sécurité;
- Affaires: exigences en constante évolution pour obtenir de meilleurs produits et des clients contents.
Le DevOps devrait donc permettre d’aligner ensemble les objectifs de ces trois aspects.
De plus, je vais être à nouveau déplaisant, mais sans l’aspect des tests automatisés, il est très difficile, voire impossible, de faire du DevOps convenablement. Eh oui, il est temps de vous réveiller si vous ne faites actuellement aucuns tests automatisés sur vos systèmes ! Et idéalement, il faut les faire AVANT le code en mode TDD (Test-Driven Development). Cela vous permettra de clarifier les intentions et diriger les efforts avant d’écrire le code de production.
Pour faire des tests automatisés correctement, des approches Agile et un paquet de pratiques d’ingénierie Agile sont aussi très utiles.
Et si on voyait le DevOps comme l’apogée de l’Agilité, soit la poursuite logique de notre transition vers l’Agilité par la maîtrise des approches Agile, qui sont sensés pour nous dans notre contexte, afin de pouvoir livrer en continu? Bref, voir le tout comme un rassemblement de forces (ou pratiques) Agile nous poussant vers le DevOps!
Eh oui, le DevOps est probablement l’objectif ultime à atteindre! Avec lui, on relève toutes sortes de points à améliorer, pas juste au niveau de l’équipe de développement. C’est comme de l’amélioration continue au niveau de l’entreprise ou organisme au complet.
Et la beauté dans tout cela, c’est qu’on a pas besoin de maîtriser toutes les nombreuses pratiques Agile, les valeurs, le Lean Software Development et le Lean Startup pour faire du DevOps. Pas non plus obligé de se développer comme les Amazon et Netflix de ce monde avec leurs méga infrastructures. On peut y aller à petits pas, comme mentionné par Kent Beck dans son XP Programming. Voici quelques exemples:
- Passer de 2 à 4 livraisons par année est un objectif très louable;
- Automatiser graduellement les trucs effectués manuellement pour gagner continuellement en productivité;
- Se bâtir une suite de tests automatisés sur nos composants de logique d’affaires;
- Etc.
En fin de compte, il vaut probablement mieux évoluer vers de petites livraisons avec peu de changement que de grosses livraisons avec beaucoup de modifications et de risques. On peut donc y voir ici un très bon ROI potentiel si on investit dans le DevOps.
Quand on implante DevOps, il ne faut pas oublier de voir à pouvoir se remettre d’une mauvaise mise en production rapidement. Il faut ainsi permettre des erreurs dans un environnement sécuritaire pour apprendre et arrêter de faire tout le temps les mêmes choses à chaque mise en production sans se remettre en question.
Il est fort probable qu’un changement de culture soit également nécessaire dans votre entreprise. Mais rien n’est impossible, même chez vous, peu importe le contexte. On peut trouver plusieurs exemples d’entreprises qui ont mis des applications Legacy dans un mode DevOps, notamment afin de les revitaliser.
J’espère que cet article a su démystifier le « buzzword » DevOps qu’on entend régulièrement de nos jours.
Références:
Excellence Agile 