Analyser l’intégration continue
L’intégration continue est l’une des huit fonctionnalités de la taxonomie DevOps.
Découvrez pourquoi l’intégration continue est nécessaire
Le 23 septembre 1999, la sonde spatiale Mars Climate Orbiter a dû replier ses panneaux solaires pour les protéger d’une rentrée involontaire dans la haute atmosphère de Mars.
Une fois en orbite, le satellite était censé envoyer des photos de Mars vers la Terre pendant plusieurs années. Malheureusement, la sonde s’est consumée dans l’atmosphère martienne.
Un bogue dans le logiciel du centre de contrôle, qui avait été fourni par une tierce partie, calculait la valeur en unités impériales, c’est-à-dire, en livres-force seconde. Le logiciel développé par la NASA s’attendait à une valeur en unités métriques : les newton seconde. Étant donné que ces valeurs n’avaient pas été correctement converties, des écarts de position, initialement légers, se sont additionnés sur des millions de kilomètres.
Les personnes en charge de l’assurance qualité n’avaient pas remarqué l’utilisation des unités impériales dans le logiciel tiers, alors même que les normes de programmation de la NASA exigeaient à l’époque l’utilisation d’unités métriques. Les calculs avaient également dû être effectués à la main plutôt qu’avec le logiciel fourni, en raison des erreurs de format de fichier et de bogues divers que présentait ce logiciel. Cette situation illustre très bien la nécessité d’une intégration continue.
Explorer l’intégration continue
L’intégration continue est un mindset et une stratégie d’équipe. En outre, l’auteur et conférencier Martin Fowler dit que l’intégration continue est une pratique de développement logiciel dans laquelle les membres d’une équipe intègrent leur travail fréquemment (au minimum une fois par jour pour chaque membre), ce qui entraîne plusieurs intégrations par jour.
Chaque intégration est vérifiée au moyen d’une génération automatisée (test compris) afin de détecter les erreurs d’intégration le plus tôt possible.
Lorsqu’elle est utilisée correctement, cette approche permet de réduire les problèmes d’intégration en les détectant plus tôt dans le processus.
Les objectifs de l’intégration continue sont les suivants :
- Exploiter le potentiel de la collaboration
- Permettre le développement parallèle
- Réduire la dette d’intégration
- Agir comme une barrière qualité
- Tout automatiser !
Notes
Notez que les objectifs de l’intégration continue incluent la collaboration continue, la livraison continue et la qualité continue.
Que se passe-t-il quand il n’y a pas d’intégration continue ? Un manque d’intégration continue aboutit souvent aux situations suivantes :
- Des cycles de développement très longs
- Code non compilable
- Code source non fonctionnel, à n’importe quel stade
- Gel du code
- De nombreux bogues et échecs de génération
- Branches à longue durée de vie, entraînant des efforts de fusion s’étalant sur plusieurs jours
- Code manquant dans le contrôle de code source
- Failles de sécurité détectées à un stade avancé du cycle de développement
- Dette technique importante
- Couverture du code faible ou inexistante
- Diminution de la qualité globale
- Une communication et une collaboration limitées
- Code ne respectant pas les normes de programmation
- Peu de revues du code, voire aucune
- Tests effectués à un stade avancé du cycle de développement
- Tests souvent effectués manuellement (voire pas du tout)
Les points d’intégration correspondent à la boucle de feedback rapide qui est utilisée pour améliorer le système. Lorsque les délais des points d’intégration sont décalés, le projet est en danger. Voici ce que dit Dantar Oosterwal à ce sujet dans son livre The Lean machine:
La caractéristique principale des points d’intégration est qu’ils contrôlent le développement du produit. Ils sont le levier qui améliore le système. Lorsque les délais des points d’intégration sont décalés, le projet est en danger.
Dantar Oosterwal, The Lean Machine
© Scaled Agile, Inc.
Si vous vous demandez si votre équipe applique réellement l’intégration continue, posez-vous les questions suivantes pour le savoir.
- Les développeurs utilisent-ils tous le « trunk based development » ?
- Chaque modification apportée à un trunk déclenche-t-elle un processus de génération ?
- En cas d’échec de la génération et des tests, l’équipe corrige-t-elle la build en quelques minutes ?
Les performances sont également influencées par la présence ou l’absence de l’intégration continue. Les données collectées et analysées dans le livre The Science Of DevOps – Accelerate – Building and scaling high performing technology organizations de Nicole Forsgren, Jez Humble et Gene Kim montrent que, pour les équipes peu performantes, l’accélération de la vitesse de commercialisation entraîne une diminution de la qualité.
À l’inverse, les équipes les plus efficaces parviennent à maintenir leur niveau de qualité lorsqu’elles accélèrent la vitesse de commercialisation. Leurs cycles de déploiement sont plus courts (et moins complexes), et elles utilisent l’intégration continue pour corriger immédiatement les problèmes, augmentant ainsi le flux et l’efficacité.
| 2017 | Équipes très efficaces | Équipes moyennement efficaces | Équipes peu efficaces |
|---|---|---|---|
| Fréquence de déploiement | Plusieurs fois par jour | 1 fois par semaine/1 fois par mois | 1 fois par semaine/1 fois par mois |
| Délai de modification | < 1 heure | 1 fois par semaine/1 fois par mois | 1 fois par semaine/1 fois par mois |
| Temps moyen de résolution | < 1 heure | < 1 jour | De 1 jour à 1 semaine |
| Taux d’échec des modifications | 0-15 % | 0-15 % | 31-45 % |