5 pièges courants du CI / CD - et comment les éviter

Devops est peut-être l'un des termes les plus flous du développement logiciel, mais la plupart d'entre nous conviennent que cinq activités font du devops ce qu'il est: intégration continue, livraison continue, infrastructure cloud, automatisation des tests et gestion de la configuration. Si vous faites ces cinq choses, vous faites des devops. Il est clair que tous les cinq sont importants pour avoir raison, mais il est trop facile de se tromper. En particulier, l'intégration continue et la livraison continue (CI / CD) peuvent être les mouvements de développement les plus difficiles à maîtriser.

L'intégration continue (CI) est un processus dans lequel les développeurs et les testeurs valident en collaboration un nouveau code. Traditionnellement, les développeurs écrivaient du code et l'intégraient une fois par mois à des fins de test. C'était inefficace - une erreur de code d'il y a quatre semaines pourrait forcer les développeurs à réviser le code écrit il y a une semaine. Pour surmonter ce problème, CI dépend de l'automatisation pour intégrer et tester le code en continu. Les équipes Scrum utilisent au moins quotidiennement le code de commit CI, tandis qu'une majorité d'entre elles commettent du code pour chaque changement introduit.

La livraison continue (CD) est le processus de création continue d'artefacts libérables. Certaines entreprises publient aux utilisateurs une ou même plusieurs fois par jour, tandis que d'autres publient le logiciel à un rythme plus lent pour des raisons de marché. Dans tous les cas, la capacité de libération est testée en permanence. Un déploiement continu est possible grâce aux environnements cloud. Les serveurs sont configurés de manière à ce que vous puissiez effectuer un déploiement en production sans arrêter ni mettre à jour manuellement les serveurs.

Ainsi, CI / CD est un processus de développement continu, de test et de livraison de nouveau code. Certaines entreprises comme Facebook et Netflix utilisent CI / CD pour réaliser 10 versions ou plus par semaine. D'autres entreprises ont du mal à atteindre ce rythme car elles succombent à un ou plusieurs des cinq pièges dont je parlerai ensuite.

Piège CI / CD # 1: Automatiser d'abord les mauvais processus

Ce piège a tendance à frapper les organisations qui passent du développement en cascade aux devops. Les nouvelles organisations ont l'avantage de mettre en œuvre CI / CD à partir de zéro. Les entreprises existantes doivent progressivement passer d'un développement manuel à un développement hautement automatisé. La transition complète peut prendre plusieurs mois, ce qui signifie que vous devez être itératif dans la façon dont vous adoptez CI / CD.

Lorsque vous demandez: "Cela doit-il être automatisé maintenant?" parcourez la liste de contrôle suivante:

  1. À quelle fréquence le processus ou le scénario est-il répété?
  2. Combien de temps dure le processus?
  3. Quelles personnes et quelles dépendances de ressources sont impliquées dans le processus? Provoquent-ils des retards dans CI / CD?
  4. Le processus est-il sujet aux erreurs s'il n'est pas automatisé?
  5. Quelle est l'urgence d'automatiser le processus?

À l'aide de cette liste de contrôle, vous pouvez hiérarchiser les étapes d'une implémentation CI / CD. Tout d'abord, automatisez le processus de compilation du code. Idéalement, vous intégrerez du code plusieurs fois par jour (1). Manuellement, le processus prend de quelques minutes à quelques heures (2). Cela bloque la sortie jusqu'à ce que le compilateur termine la tâche (3). Elle est également sujette à l'erreur humaine (4), et comme CI / CD est une chimère sans intégration automatisée, c'est urgent (5).

Nous pouvons exécuter la même liste de contrôle pour les tests. Lorsque vous passez à CI / CD, vous vous demandez peut-être: Devrions-nous d'abord automatiser les tests fonctionnels ou les tests d'interface utilisateur? Les deux seront répétés au moins une fois par jour (1). Les deux peuvent prendre de deux à trois heures pour une application de taille moyenne (2). Mais ils impliquent de multiples dépendances (3). Si vous automatisez les tests fonctionnels, vous n'aurez peut-être pas besoin de mettre à jour le script d'automatisation aussi fréquemment. L'interface utilisateur, en revanche, change souvent et nécessite donc des changements de script fréquents. Bien que les deux soient sujets aux erreurs (4), vous devez donner la priorité aux tests fonctionnels avant les tests d'interface utilisateur pour tirer le meilleur parti de vos ressources (5).

Faisons cela une fois de plus avec le processus de configuration des environnements. Ce scénario ne se répète fréquemment que si vous êtes en période d'embauche ou si vous rencontrez une forte rotation (1). C'est un processus assez long qui peut prendre plusieurs heures, voire plusieurs jours (2). Les nouveaux membres de l'équipe ne peuvent rien faire d'utile sans les environnements, il y a donc clairement une dépendance et un retard (3). Je ne dirais pas que le processus est sujet aux erreurs (4), est-ce donc toujours urgent (5)? Je penche pour oui, mais je donnerais toujours la priorité à l'intégration et aux tests fonctionnels en premier.

Il n'y a pas de surautomatisation. Si vous aviez des ressources illimitées, vous automatiseriez tout ce qui est possible. Cela dit, vous ne pouvez pas réaliser une automatisation totale des tests. Parfois, vous pouvez diviser les tâches en segments plus petits et automatiser les correctifs. Parfois, vous devez simplement documenter le processus en détail et l'exécuter manuellement.

Piège CI / CD n ° 2: Déploiement continu confus pour une livraison continue

Le déploiement continu est le concept selon lequel chaque modification apportée à la base de code sera déployée presque immédiatement en production si les résultats du pipeline sont couronnés de succès. Cela est terrifiant pour la plupart des organisations car les changements rapides de produits peuvent effrayer les utilisateurs.

Les entreprises pensent que si elles ne pratiquent pas le déploiement continu, elles ne font pas de CD. Ils ne font pas la distinction entre le déploiement continu et la livraison continue.

La livraison continue est le concept selon lequel chaque modification de la base de code passe par le pipeline jusqu'au point de déploiement dans des environnements hors production. L'équipe trouve et résout les problèmes immédiatement, pas plus tard lorsqu'elle prévoit de publier la base de code.

La base de code est toujours à un niveau de qualité sûr pour la publication. Quand libérer la base de code en production est une décision commerciale.

Alors que le déploiement continu déstabilise la plupart des organisations, la livraison continue résonne avec elles. La livraison continue leur permet de contrôler le déploiement du produit, la fonctionnalité et les facteurs de risque. Il est temps pour les tests alpha, pour les clients bêta, pour les premiers utilisateurs, etc.

Piège CI / CD # 3: Manque de tableaux de bord et de métriques significatifs

Dans les implémentations CI / CD, l'équipe Scrum peut créer un tableau de bord avant que les membres ne sachent ce qu'ils doivent suivre. En conséquence, l'équipe est la proie d'une erreur logique: «Ce sont les paramètres que nous avons, ils doivent donc être importants.» Effectuez plutôt une évaluation progressive avant de concevoir un tableau de bord.

Différents membres d'une organisation informatique, et même divers membres d'une équipe Scrum, ont des priorités différentes. Par exemple, les employés d'un centre d'opérations réseau (NOC) aiment les indicateurs rouges, jaunes et verts. Ces tableaux de bord de feux tricolores permettent au personnel des CNO de distinguer les problèmes sans lire de texte dense ni mettre à l'épreuve leurs capacités d'analyse. Les feux de signalisation permettent de gérer des centaines de serveurs.

Vous pourriez être tenté d'utiliser un tableau de bord de feux de signalisation pour CI / CD aussi. Vert, nous sommes sur la bonne voie. Jaune, nous ne sommes pas sur la bonne voie, mais nous avons un plan pour y remédier. Rouge, nous ne sommes pas sur la bonne voie et avons probablement besoin de changer nos objectifs.

Ce tableau de bord est probablement utile à un scrum master, mais qu'en est-il du vice-président du développement ou du directeur technique? Si une équipe Scrum a 350 heures de travail devant pour un sprint de deux semaines, et que ses 10 membres sont responsables de 35 heures chacun, ils recevront un nombre correspondant de points d'histoire. La direction supérieure pourrait être moins intéressée par le statut des points d'histoire et plus curieuse du taux de «burndown»: la vitesse d'achèvement des tâches. Les membres de l'équipe portent-ils leurs charges? À quelle vitesse? S'améliorent-ils avec le temps?

Malheureusement, les taux de burndown peuvent être trompeurs si les différentes parties prenantes ne comprennent pas les habitudes convenues de l'équipe Scrum. Certaines équipes brûlent des points au fur et à mesure. D'autres attendent jusqu'à la fin du sprint pour brûler les points ouverts. Le tableau de bord devrait en tenir compte.      

Si vous pouvez évaluer les données souhaitées par tout le monde et établir une description standard de ce que ces données signifient, vous pouvez concevoir un tableau de bord utile. Mais ne soyez pas obsédé par la substance au détriment de l'apparence. Demandez à quoi les parties prenantes veulent qu'il ressemble. Les graphiques, le texte ou les nombres seraient-ils les meilleurs?

Telles sont les considérations à étudier dans une évaluation progressive. Ils illustrent à quel point il est difficile de créer un tableau de bord CI / CD utile et de rendre tout le monde heureux. Trop souvent, le membre de l'équipe le plus vocal détourne le processus, et d'autres se sentent frustrés que le tableau de bord ne réponde qu'aux préférences d'une seule personne. Écoutez tout le monde.  

Piège CI / CD # 4: Manque de coordination entre l'intégration continue et la livraison continue

Cet écueil nous ramène à notre définition consensuelle des devops, selon laquelle l'intégration continue et la livraison continue sont deux éléments différents. CI alimente le CD. La mise en œuvre d'un pipeline d'intégration continue décent et d'un système de livraison continue complet prend des mois et nécessite une collaboration. L'assurance qualité, l'équipe devops, les ingénieurs opérationnels, les scrum masters, tous doivent y contribuer. L'aspect le plus difficile de CI / CD est peut-être ce facteur humain plutôt que tout défi technique dont nous avons discuté. Tout comme vous ne pouvez pas programmer une relation saine entre deux personnes, vous ne pouvez pas automatiser la collaboration et la communication.

Pour évaluer ce niveau de coordination, comparez votre processus CI / CD aux meilleurs du secteur. Des entreprises comme Netflix peuvent terminer l'intégration, les tests et la livraison en deux à trois heures. Ils ont établi un système qui passe le code de main en main sans indécision ni discussion. Non, ce n'est pas 100% automatisé car c'est impossible avec la technologie actuelle.

Piège CI / CD n ° 5: équilibrer la fréquence d'exécution des tâches d'intégration continue et l'utilisation des ressources

Les travaux d'intégration continue sont censés être déclenchés pour chaque changement introduit dans le code. Les travaux réussis permettent aux modifications de s'exécuter tandis que les échecs rejettent les modifications. Cela encourage les développeurs à enregistrer de plus petits morceaux de code, ce qui déclenche plus de builds en une journée. Cependant, les travaux d'intégration continue inutiles consomment des ressources, ce qui fait perdre du temps et de l'argent.

Étant donné que ce processus implique une utilisation importante des ressources (CPU, puissance, temps), le logiciel doit être divisé en composants plus petits pour créer des pipelines plus rapides. Ou les travaux d'intégration continue doivent être conçus pour des enregistrements par lots qui sont d'abord testés localement. L'objectif est de trouver un équilibre entre la fréquence d'exécution des jobs d'intégration continue et l'utilisation des ressources.

Gardez l'objectif en vue

Alors que nous creusons les pièges de CI / CD - avec toute sa terminologie ésotérique - il est facile de perdre de vue pourquoi cela est important. En fin de compte, CI / CD est essentiel car il répond aux objectifs commerciaux.

Les responsables technologiques savent que l'évolution continue, les solutions rapides et les résultats de qualité créent et fidélisent les clients. Ils savent qu'une version ratée invite un matraque aux critiques de l'App Store, et retrouver des critiques élevées est plus difficile que de les garder. Devops peut créer une meilleure expérience de travail pour votre équipe, mais ce n'est pas la raison pour laquelle les entreprises implémentent les devops.

En termes simples, les écueils de CI / CD méritent d'être examinés car des milliards de dollars sont en jeu. Bien que je ne vous suggère pas d'ajouter un ticker boursier ou un suivi des critiques de l'App Store à votre tableau de bord CI / CD, je vous exhorte à rester conscient de cela. Beaucoup dépend des minuties de CI / CD.

Zubin Irani est co-fondateur et PDG de cPrime, un cabinet de conseil complet qui met en œuvre des transformations agiles et fournit des solutions agiles à plus de 50 entreprises du Fortune 100 et à de nombreux plus grands employeurs de la Silicon Valley.

Le New Tech Forum offre un lieu pour explorer et discuter des technologies d'entreprise émergentes avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre choix des technologies que nous pensons importantes et qui intéressent le plus les lecteurs. n'accepte pas les supports marketing pour la publication et se réserve le droit de modifier tout le contenu fourni. Envoyez toutes vos demandes à [email protected]