Formation DevOps écrite

Comment concevoir votre pipeline de livraison et de déploiement continus en DevOps ?

Dans de nombreuses organisations, probablement la vôtre aussi, les développeurs écrivent leur code isolément dans des branches distinctes. Cette façon de travailler semble favoriser leur productivité individuelle, mais elle nuit à celle de l’équipe.

Des branches distinctes compliquent la fusion du code de plusieurs développeurs. Pour intégrer les différents fragments de code, les faire fonctionner ensemble et livrer des fonctionnalités utiles à vos clients, il faut généralement mobiliser plusieurs développeurs, reprendre une grande partie du travail et résoudre des conflits qui auraient dû l’être depuis longtemps.

Sans intégration continue, la difficulté s’aggrave

Paradoxalement, parce que la fusion du code est difficile et fatigante pendant le développement, la plupart des équipes attendent de remettre leur application aux personnes chargées des tests d’intégration ou d’acceptation utilisateur pour fusionner leur code, ce qui aggrave le problème. Elles rendent les équipes d’assurance qualité seules responsables de la réussite de l’intégration et de la qualité du travail commun. Cela explique les retards, l’explosion des dépassements budgétaires, la baisse du moral et de la motivation, les objectifs et promesses non tenus, et les quelque 600 milliards USD que les entreprises du monde entier gaspillent chaque année en travaux informatiques non budgétés et non planifiés, c’est-à-dire en reprises et solutions de contournement.

Comment le développement fondé sur le tronc, la branche principale du code, peut-il vous aider ?

Pour résoudre ce problème, combinez le développement fondé sur le tronc (la branche principale du code) avec l’intégration continue et l’automatisation des tests. Il s’agit d’un modèle de gestion des branches dans lequel les développeurs collaborent sur le code dans une seule branche, appelée « tronc ». Ils résistent à toute pression visant à créer d’autres branches de développement de longue durée.

Le développement fondé sur le tronc facilite l’intégration continue et, par extension, la livraison continue. Quand les développeurs intègrent leurs changements au tronc plusieurs fois par jour, chacun satisfait facilement à l’exigence centrale de l’intégration continue, qui consiste à intégrer son code au tronc au moins une fois toutes les 24 heures. Le code source reste ainsi livrable à la demande, ce qui rend possible la livraison continue.

L’intégration continue permet de livrer de plus petits lots de code prêts à être déployés

Les intégrations fréquentes de vos développeurs permettent de réduire la taille des lots de développement et de livraison, ce qui améliore la qualité et facilite la résolution des problèmes et des conflits. L’intégration continue avec des intégrations quotidiennes encourage votre équipe à produire du code déployable et utile en plus petits lots, tout en préservant l’intégrité des dispositifs d’intégration et de livraison continues. Le dépôt commun facilite également la concertation, la prise de décision et les retours rapides.

Chaque fois que du code est intégré, votre système d’intégration continue exécute les tests automatisés pour les fonctions et fonctionnalités qui dépendent du module modifié ou sont touchées par celui-ci. En cas de problème, la personne qui a intégré le code est chargée de le corriger en priorité absolue. Cela permet aux autres membres de l’équipe de continuer à intégrer leur travail au tronc. Pour préserver la stabilité et la fiabilité du tronc, aucune autre modification de ce module n’est autorisée tant que la modification erronée n’a pas été rapidement corrigée ou annulée.

Si vous n’êtes pas d’accord avec ce principe DevOps, posez-vous cette question : pourquoi ajouter du nouveau code à un module qui contient déjà des erreurs ?

Vous pouvez avoir de bonnes raisons, mais veillez à éviter la dette technique et l’empilement de solutions de contournement.

Les validations de code soumises à des contrôles offrent une protection supplémentaire au développement fondé sur le tronc

Votre équipe DevOps peut également s’appuyer sur des validations de code soumises à des contrôles pour améliorer la qualité et ajouter une protection supplémentaire au tronc.

Chaque fois qu’un développeur tente d’intégrer du code, les tests automatisés s’exécutent d’abord pour le valider. Le code n’est officiellement intégré au tronc qu’en cas de réussite de la validation.

Utilisez des environnements proches de la production à toutes les étapes du flux de valeur logiciel

Un autre problème courant tient aux différences entre la production et les environnements de préproduction, dont le développement, l’intégration et les tests. Ces différences concernent les configurations, versions et niveaux de correctifs des systèmes d’exploitation, bases de données, outils tiers et API. Il peut aussi s’agir de versions différentes de votre propre code, dispersées entre divers environnements. Même de très faibles écarts entre les versions de la JVM en préproduction et en production peuvent déterminer la réussite de tout votre déploiement. Sans une maîtrise complète de vos environnements et de leur contenu, vous ne savez pas ce que vous en obtiendrez.

Intégrez la gestion des environnements à vos activités quotidiennes de développement et de livraison

Vos systèmes de préproduction devraient donc reproduire vos systèmes de production. Donnez à l’équipe les moyens de créer automatiquement des environnements en libre-service et à la demande pour effectuer son travail quotidien en toute sécurité dans des conditions proches de la production.

Le code de vos logiciels et les environnements où il s’exécute contribuent tous deux à votre flux de valeur informatique. Vos spécialistes du développement et de l’exploitation doivent reconnaître que ce flux repose sur deux composantes d’égale importance :

1. Le code qui permet de produire les logiciels apportant de la valeur à vos clients internes ou externes, ou aux deux.
2. Le code qui permet de construire les environnements de préproduction et de production qui hébergent vos logiciels.

Utilisez votre source unique de vérité (le tronc) pour gérer vos logiciels et vos environnements
(c’est-à-dire adoptez l’infrastructure en tant que code, ou IaC)

Avec le DevOps, les tâches de construction des environnements de préproduction et de production font partie du tronc. C’est la définition la plus pure de l’infrastructure en tant que code (IaC). Vos spécialistes du développement et de l’exploitation construisent ensemble cette infrastructure. Dans une organisation cloisonnée, les équipes d’exploitation connaissent souvent mal les particularités des logiciels à héberger.

Pour accorder la même importance au code des logiciels et à celui des environnements, stockez-les tous deux dans votre source unique de vérité, le tronc.

Pour construire vos systèmes de préproduction et de production et votre pipeline de déploiement, y compris les dispositifs d’intégration et de livraison continues, stockez dans votre système de gestion des versions le code logiciel, les configurations, les scripts et tout ce qui est nécessaire à votre chaîne de livraison de bout en bout. Pour modifier durablement un paramètre d’environnement, changez-le dans les scripts qui construisent l’environnement. Le prochain membre de l’équipe DevOps qui en créera un n’aura ainsi pas à tout refaire.

La plupart des documentations détaillées deviennent vite obsolètes. Vous avez donc intérêt à tenir à jour vos scripts de construction des environnements. Sans environnements en libre-service et à la demande, votre infrastructure cloud restera une plateforme d’hébergement sous-utilisée et votre initiative DevOps une démarche d’amélioration sous-exploitée de plus. Vous devriez pouvoir construire tous vos environnements de production et de préproduction à partir de votre système de gestion des versions. Avec le DevOps, il est plus simple et rapide de reconstruire un environnement que de le réparer. Les modifications manuelles ne sont plus permises. Seuls le code et la configuration doivent reconstruire, configurer et démarrer les environnements.

Vous avez une nouvelle définition de fini (DoD)

Une fois votre dispositif de livraison continue et votre pipeline opérationnels, vous avez besoin d’une nouvelle « définition de fini » (DoD).

Une tâche est désormais considérée comme « terminée » lorsque les fonctionnalités et avantages associés pour le client sont :

• créés à partir du tronc automatiquement ou en un clic,
• testés dans des environnements proches de la production avec des tests automatisés,
• présentés en démonstration dans des environnements proches de la production,
• prêts à être déployés ou, mieux encore, déjà déployés dans les environnements de production en service, automatiquement ou en un clic.

CONCLUSION

Avec le DevOps, l’intégration du code fait partie du travail quotidien, au lieu d’attendre la fin des projets. Les développeurs, les équipes d’exploitation et les spécialistes de la sécurité de l’information répètent de nombreuses fois le déploiement de leur travail dès le cycle de développement logiciel, ce qui augmente les chances d’un déploiement en production sans difficulté.

En adoptant l’intégration continue, vous bénéficierez aussi d’un débit métier plus élevé, de logiciels et d’environnements plus stables, d’une meilleure satisfaction au travail et d’un meilleur service à vos clients internes et externes.