Le rapprochement entre les équipes de développement et d’exploitation est l’élan principal du mouvement DevOps. Pour appréhender l’interactions entre ces deux équipes, il faut comprendre le cycle de vie d’une application. Si celui-ci comporte une phase initiale d’analyse des besoins et d’études de faisabilité entre autre, il passe, pour ce qui concerne notre sujet, par une chaine de montage (un workflow pour les anglophones) qui va de la conception à la mise en production. Du développement à l’exploitation.

Cette présentation est plus de la vulgarisation qu’un discours hautement académique, je prends donc le parti de la simplification et de présenter le cycle de vie comme l’adjonction de deux cycles distincts, celui du développement et celui du déploiement dans les environnements de recette et de production. On pourrait palabrer sur la pertinence de cette césure, et il est vrai que certaines méthodes voire outils ne les distinguent pas aussi franchement, mais le but avoué de cet article est de présenter les deux concepts qui ainsi s’appuient sur un cycle de vie, respectivement le Continuous Integration et Continuous Delivery (Intégration continue et Livraison continue pour les francophones).

Bicéphale

Quant à ce choix de séparations en deux sous-cycles, ici nul débat, mais je prends le soin de présenter mes arguments pour une meilleure compréhension.
Ces deux parties peuvent être sous des directions bien distinctes aux méthodes différentes. Il est fréquent que les directions de développement et de production soient sous deux gouvernances, et donc dépendantes de deux budgets distincts (accentuant la différence d’approche). Un autre cas commun est celui d’une application fournie par un éditeur externe prenant de facto en charge le cycle de développement. Ou bien encore, lorsque la production est à la main d’un sous-traitant assurant les recettes et l’exploitation.

Chacun a pu observer ces différents cas. Et cette fracture est courante ! D’aucun dirait que ma mise en lumière est à l’encontre d’une résorption. Que nenni, je vais présenter les deux aspects pour mieux comprendre la charnière qui fait souvent défaut. Et le DevOps de rapprocher.

Le cycle de vie

Comme précisé en introduction, le cycle de vie du déploiement d’un développement logiciel passe par des phases en amont du développement que je passe sous silence.

La présentation commence donc au développement avec ses étape de programmation, de compilation/création. Ca fait plus pro’ en anglais : coding & build. Puis les T.U. les tests unitaires, soit U.T. Unit Testing en anglais, la série de tests qui valident que le programme ne produit pas d’erreurs de syntaxe ou de bogue décelable sans compétence particulière. Par exemple, une page blanche, une mise en page totalement erratique, une horloge uniquement en secondes. Bref est-ce que ça présente bien.

Puis suivent quelques environnement de recette (Q.A. Quality Assurance qui permettront de valider qui les interfaces, qui le fonctionnel, qui la charge. Pour enfin se terminer par la sacro-sainte mise en production.

Le décor est planté, voyons donc ce qui se cache en substance derrière les termes Continuous Integration et Continuous Delivery. Et je dis en substance parce qu’ils font l’objet de livres entiers et qu’il devrait faire l’objet d’un article complet sur un blog tel que celui de votre serviteur.

Continuous Integration

Pour brosser un tableau rapide de ce concept, c’est un ensemble de pratiques qui se traduit de façon tangible par la mise en place outillés d’un flux qui porte au plus haut la valeur ajoutée sur les 5 points suivants :

• Repository ou Vault
• Versionning
• Automatic Build
• Automatic Testing
• Code Quality

Le Repository ou Vault traduit par Dépôt ou Coffre-fort, est la zone sanctuarisée de stockage des sources et objets. C’est ici et pas ailleurs (et surtout pas sur les postes personnels). Elle est connue et accessible de toutes les personnes compétentes, elle est sauvegardée et préservée comme il se doit.
Le versionning anglicisme pour la gestion des versions, permet de retrouver toutes les versions d’un code et/ou objet.
L’automatic build est comme son nom laisse supposer l’automatisation de la construction de l’application à partir des sources. Ce qui gère les dépendances ou les ordres de constitutions les mains posées sur le café.
L’automatic testing est identique mais pour les tests. Peu de valeur ajoutée à renseigner « Toto » et constater que la sortie sera « Hello Toto ! ».. Autant que le développeur consacre son énergie à ses compétences elles irremplaçables.
Le code quality ou revue de code est le contrôle de la qualité de ce qui est produit par l’équipe de développement. Construire pour durer exige de la qualité et le code ne déroge surtout pas à cette règle.

Pour clore cette présentation simplificatrice, je dirais qu’une mise en place optimale (même si tout est toujours perfectible) permet au développeur de se consacrer pleinement à sa tâche, le développement et uniquement le développement, tout le reste étant géré en automatique. Autrement dit, le développeur n’effectue que la partie motivante et intéressante pour lui, laissant les tâches répétitives et rébarbatives à l’automatisation. Le gain est clairement la qualité du code, mais aussi la qualité de vie du développeur générant un élan d’implication, et donc, goto beginning, de la qualité de code.

Le bien-être du développeur est une des clefs du bien-coder.

Continuous Delivery

Une première approche de cette notion est disponible dans mon article Vers le Continuous Delivery. Ici à l’instar du tableau brossé pour le Continuous Integration, voyons les points forts :

• Automatic promotion
• Automatic testing
• Performance testing
• Monitoring
• Measures
• Controls
• Auditable
• Documentation

L’automatic promotion est sans surprise la capacité à déployer une application avec toute l’infrastructure nécessaire en cliquant sur le bouton « déploiement », uniquement.
L’automatic testing est l’automatisation des tests. Tout comme le déploiement, l’idée est de lancer la batterie de tests par automate. D’un côté les cas de tests, de l’autre les résultats attendus, autant automatiser ces vérifications peu amènes.
Le performance testing, ou la tenue à la charge est difficile à imaginer en manuel, alors que simuler 100000 connexions est une chiquenaude pour un robot.
Le monitoring doit être embarqué et déployé ! Quand on installe de nouvelles fonctionnalités et/ou infrastructure il faut mettre en place un monitoring, une surveillance. Et donc il faut qu’il fasse partie du déploiement, et non après coup, quand on aura le temps, on verra ça plus tard (quelle ineptie !).
Les measures est un des points forts trop souvent négligé. Ce menu est-il utilisé ? Combien de fois cette option est sollicitée ? Pour répondre à ses questions il faut mettre en place et déployer une métrologie dans le même déploiement que la fonctionnalité elle-même.
Les controls de validité, de cohérence, de dépendances, en bref, est-ce que le grand tout résultant du déploiement va être pleinement compatible !? Ces contrôles doivent eux aussi faire parti du déploiement.
Il faut que tout déploiement soit auditable, pour les aficionados d’ITIL, que le lien avec l’ITSM pour « Information Technology Service Management » soit inclus. Telle ligne de code a été ajouté pour corriger le bug déclaré dans tel ticket incident.
Le déploiement de la documentation parait un voeux pieu. L’idée est que toute nouvelle fonctionnalité ou tout aménagement s’accompagne d’une documentation et donc il parait évident qu’elle doit elle aussi faire partie du lot de livraison.

Un précédent article De l’intérêt du Continuous Delivery pour le business présente certains avantages d’une telle mise en oeuvre. Avec une optique d’exploitation, l’apport est que tout est cadré, aucun oubli, tout est préparé et re-préparé et encore préparé en amont, faisant de la sacro-sainte mise en production un parcours de santé.
Les exploitants gagnent en confort puisque tout est livré (surveillance et documentation incluses) dument testé. Ce qui leur permet de s’investir non pas dans la gestion d’incidents bénins à la petite semaine, mais dans l’optimisation de leur exploitation et les remontées vers le développement pour les améliorations. Là encore se concentrant sur la partie à haute valeur ajoutée, c’est l’intérêt de leur travail qui est accru. Joie et bonheur dans leur coeur.

Le confort de l’exploitant est une des clefs de la stabilité de la production.

Charnière à suivre…