Boucle de RétroAction DevOps

Dans les précédentes parties de cette formation devops, nous avions vu ce qui avait amené à l'émergence de la démarche DevOps. Nous avions vu également grands principes qui ont été posés comme les fondations. Nous allons voir maintenant comment tous ces concepts ont été implémentés pour donner ce que nous connaissons aujourd'hui sous le nom de boucle DevOps (devops loop).

L'origine de la boucle infinie DevOps

Le cycle de vie DevOps puisse ses sources dans les concepts de l'amélioration continue et de l'agilité. Elles sont apparues la première fois dans le livre **The Phoenix Project **, publié en 2013. Gene Kim explique dans cet article que « La troisième voie consiste à créer des boucles de rétroaction de droite à gauche. L’objectif de presque toutes les initiatives d’amélioration des processus est de raccourcir et d’amplifier les boucles de rétroaction afin que les corrections nécessaires puissent être continuellement livrées.

Les différentes phases de la boucle DevOps

Comment démarrer un projet DevOps

Avant de se lancer dans un projet DevOps, il est important de recueillir un certain nombre d'éléments qui vont permettre de décomposer le projet en petites tâches qui vont alimenter ce qu'on appelle la backlog.

Cette phase préparatrice consiste par le recueil de la vision et des exigences du projet. Celle-ci se poursuit par la définition de l'architecture logicielle et technique et se termine par la création de la liste des tâches, grosses mailles, permettant d'atteindre tous les objectifs fixés. Ces tâches seront ensuite décomposées en tâches plus petites permettant d'être réalisé dans un temps court, qu'on appelle un sprint. En règle générale un sprint à une durée de deux semaines.

Planifier (plan)

Maintenant que nous avons une backlog, il est temps de définir quelles sont celles qui vont être priorisées pour créer une nouvelle version de notre produit. Parmi les critères permettant de prioriser les tâches, veiller à prendre celles :

• Qui ajoute le plus de valeur à votre produit pour votre client, interne et/ou externe
• Qui permet de sécuriser et de fiabiliser votre produit.

Veillez à ce que ces tâches soient réalisables dans le temps imparti du sprint en respectant la charge de ceux qui vont les réaliser.

Réaliser (code)

Les développeurs en charge de l'écriture du code de l'application, une fois des tests locaux, sur leurs machines, réalisés avec succès, pousse le code source dans un dépôt de code géré par un gestion de versions de code.

L'intégration continue (CI)

L'intégration continue consiste à pousser continuellement les modifications de code à un gestionnaire de version de code, suite à quoi des opérations de compilation (build), d'intégration puis de test sont automatiquement menées. Les principaux objectifs de l'intégration continue sont de :

• trouver et de corriger le plus rapidement les erreurs
• améliorer la qualité
• réduire le temps nécessaire pour valider ces modifications

Assembler (buid)

Au moment de cette intégration, l'outil de pipeline CI/CD détecte cet événement et lance les actions de construction. Ce processus lance les actions nécessaires pour assembler le logiciel en intégrant les dépendances décrites dans le fichier de description de celui-ci.

Tester (verify)

Sur la base du code assemblé, une série de tests, unitaires d'intégration et de bout en bout sont lancés. Si la construction échoue ou si l'un des tests échoue, la demande d'intégration échoue et le développeur est averti afin de résoudre les problèmes.

Versionner (package)

Une fois ce processus de tests réalisés avec succès, il faut procéder à la création d'un package communément appelé un artefact. Cet artefact doit être versionné pour pouvoir l'identifier facilement. Il sera ensuite stostockéns un gestionnaire d'artefacts qui vérifie le package est bien unique. S'il existe un package portant la même version, il est rejeté et le pipeline échoue.

Le déploiement continu (CD)

La livraison ou le déploiement continu des artefacts produit par l'intégration continue se fait dans différents environnements.

Déployer

Le déploiement des artefacts produit dans la phase d'intégration peut se faire dans un ou plusieurs environnement(s) de test. Une série de tests de bout en bout sont alors exécutées pour valider cet artefact apte à être déployé sur l'environnement de production.

Attention, l'artefact déployé sur les différents environnements doit être absolument le même. On peut imaginer un simple renommage ou un déplacement dans un gestionnaire d'artefacts de production lors de l'action de promotion.

Opérer

L’équipe en charge des opérations doit s’assurer que suite au déploiement d'une nouvelle version que tout se passe bien.

Mesurer

Des outils mesurent en permanence la qualité du service rendu. Ces mesures permettent de définir, s'il est nécessaire de corriger rapidement toute erreur ou d'effectuer un retour arrière à la version précédente.

Vous pouvez mettre en place un moyen permettant à vos clients de fournir des commentaires sur le logiciel nouvellement déployé. Ces commentaires sont collectés et triés pour alimenter les exigences des futures versions.

Il est possible aussi de mesurer le temps pris par les événements suivants :

• Tout d’abord le délai de changement, donc le temps entre le commit du code et la mise en production
• La fréquence de déploiement, donc à quel intervalle le code est déployé en production
• Le temps de récupération, c'est-à-dire le temps nécessaire pour restaurer le service après un incident
• Le taux d’échec des changements ou le pourcentage des changements qui diminue le service ou requièrent une intervention

Toutes ces informations, qu'on appelle feedback vont servir à alimenter la liste de tâches. Ces nouvelles tâches seront ajoutées à celles non encore réalisés et seront priorisées pour définir qu'elles sont celles devront intégrer la nouvelle itération.

La nécessité de créer une définition of Done (DOD)

Attention, il faudra veiller auparavant à bien définir ce qu'on appelle une DOD, la “definition of done”. C'est une liste de critères à vérifier, afin de déterminer si les tickets sont vraiment terminés. Cela peut comporter :

• Un rapport de test réalisé avec succès
• Un taux de couverture de code respectant les objectifs fixés
• Un rapport de succès à l'analyse des vulnérabilités des artefacts et des dépendances
• une documentation conforme…