6 étapes pour évaluer le niveau de déploiement continu de votre organisation

Par :
Brian Dawson

ven, 01/06/2018 - 15:18

Faites-vous réellement l’intégration continue ? Si oui, avez-vous étendu les processus de votre entreprise au point de maîtriser la prochaine étape : le déploiement continu ?

D'après les rapports et données empiriques, un certain nombre d’organisations actuelles s'efforcent sans succès de suivre les principes reconnus de l'intégration continue.

Dans cet article, nous allons nous intéresser au déploiement continu. La bonne nouvelle, c'est que les organisations progressent. La mauvaise : comme pour l'intégration continue, elles sont nombreuses à surestimer leurs performances en déploiement continu.

Que sont précisément l'intégration continue et le déploiement continu ? L'intégration continue est un processus automatisé auquel l'équipe de développement a recours ; les développeurs apportent régulièrement des modifications au code source dans un répertoire central, modifications qui sont intégrées et validées en continu.  Les erreurs sont ainsi détectées et résolues au plus tôt. Cela permet de déceler les erreurs au plus tôt et ainsi de les corriger rapidement dans le processus. C’est pour cette raison que l’un des mantras de l’intégration continue est : « échoue rapidement ». Cette pratique accélère le processus de développement et permet de garantir un code de grande qualité.

Le déploiement continu étend les principes et pratiques de l'intégration continue vers la droite (en aval) dans le processus de déploiement logiciel - le code est testé et déployé en continu pour garantir qu'après chaque modification, le logiciel peut être utilisé. Le déploiement continu permet de transférer les modifications dans les environnements de pré-production ou de production, et à terme de les délivrer aux utilisateurs, de manière rapide, reproductible et fiable.  Comme pour l'intégration continue, les équipes peuvent commettre des erreurs qui seront rapidement détectées grâce aux feedbacks en environnement réel, et ainsi améliorer la valeur proposée aux clients.

Les experts en la matière affirment que pour véritablement pratiquer le déploiement continu, les équipes de déploiement doivent pouvoir répondre aux questions suivantes par l'affirmative :

  1. Votre logiciel est-il prêt à l'emploi après chaque modification ?  (Vous pouvez mettre le logiciel en production à tout moment et en toute confiance.)
  2. Toutes les parties prenantes ont-elles une visibilité sur la mise à disponibilité du logiciel ? (Le processus est automatisé, reproductible et traçable.)
  3. Un déploiement en un clic peut-il être effectué à tout moment ? (Le déploiement et la configuration du logiciel sont automatisés et reproductibles.)

Le secteur prêtant désormais une attention toute particulière au déploiement continu, il serait naturel de penser que la grande majorité des sociétés ait mis en œuvre ces bonnes pratiques intégralement et correctement. Le livre de Jez Humble et Dave Farley sorti en 2010, Continuous Delivery, a popularisé le terme en anglais et les principales sociétés technologiques telles que Netflix et Flickr ont montré au monde entier comment réaliser une dizaine de déploiements par heure.

Les chiffres nous disent autre chose. Selon le guide DZone de 2016 pour la livraison continue, la moitié des professionnels interrogés pensait suivre les pratiques du déploiement continu, mais seulement 10 % le faisaient réellement, d'après les trois critères cités plus haut. (Ils étaient 8 % en 2014.)

En un mot, si une société garantit que son logiciel est toujours prêt à être utilisé, elle pratique très certainement le déploiement continu.

Le second critère indiqué précédemment (toutes les parties prenantes ont une visibilité sur la disponibilité du logiciel) bien que non obligatoire, est important. Si une société conçoit, teste, mesure et livre un logiciel en continu avec succès, ce critère peut perdre de son importance.  Cependant, cette visibilité est souvent essentielle pour établir la fameuse « confiance » entre les développeurs (Dev) et les opérateurs (Ops) qui permet d'automatiser le processus.  Le partage de la visibilité favorise également les boucles de rétroaction cruciales.

La troisième définition (un déploiement en un clic possible à tout moment) est fondée sur le principe selon lequel un déploiement doit être un non-événement. Votre logiciel est toujours prêt à être utilisé, ce qui signifie que vous l'avez testé dans un environnement de production et dans un processus de déploiement.

En résumé, le déploiement continu est défini par les critères cités précédemment et est décrit en détail dans de nombreux écrits. Mais quelles sont les étapes fondamentales simples que les organisations peuvent suivre pour l'appliquer correctement ?

Je vous propose ici une liste de six étapes pour vous aider à véritablement évaluer votre degré de déploiement continu :

Rationaliser les modifications

Une des premières étapes consiste à accélérer vos modifications et scénarios utilisateur afin qu'ils puissent être rapidement transmis à votre canal de déploiement continu, pour soutenir l'automatisation des tests et minimiser les risques. Vous pouvez ainsi les isoler. Elles peuvent être facilement intégrées, testées et déployées en prenant moins de risques ; cela vous oblige également à penser à la valeur incrémentielle livrée à vos clients. Pour ce faire, passez du processus de développement en cascade à des méthodes lean ou agiles telles que les méthodes Kanban ou Scrum.

Utiliser un système de suivi

Avec le déploiement continu, la capacité à suivre les modifications dans le système est essentielle. L'utilisation d'un outil de suivi tel que Bugzilla ou Jira permet aux parties prenantes de collaborer tout au long du processus de livraison continue et de mesurer des indicateurs clés de performance (KPI) importants tels que la durée de cycle d'une modification.

Mettre en œuvre un système de contrôle des versions

Un outil de suivi permet de saisir et de suivre les modifications dans votre canal. Ces modifications spécifiées dans votre système de suivi représentent des modifications de code effectuées par l'équipe de développement. Le contrôle des versions permet aux équipes de savoir, à n'importe quel moment, ce qui a changé dans notre base de code et de revenir à la version précédente rapidement. Les systèmes modernes de contrôle des versions tels que Git proposent des fonctions collaboratives telles que les demandes d'extraction, qui améliorent la qualité en mettant en place un examen par les pairs.

Déployer automatiquement votre version

Pour déplacer votre version vers l'aval, il est important de pouvoir automatiser le déploiement de la version dans un environnement comme celui dans lequel il opèrera. L'aspect essentiel ici n'est pas simplement la fonction de déploiement, mais également la fourniture d'accès à l'infrastructure et à l'environnement de déploiement. Dans les processus existants, elle était généralement statique. Du fait de la vitesse à laquelle nous livrons les modifications dans un canal de déploiement continu, nous avons désormais besoin d'un accès immédiat et constant aux environnements.

Procéder au déploiement dans un environnement de type production

Vous devez fournir un accès à ces environnements de type production le plus tôt possible dans le canal, idéalement dès le développement. Il s'agit d'un point important, car notre objectif de déploiement continu est d'accélérer les changements et de détecter les problèmes rapidement. Si nous déployons notre logiciel dans des environnements autres que de production, il existera toujours des inconnues au moment du déploiement. Par conséquent, nous ne pouvons pas prétendre que notre logiciel est toujours prêt à être utilisé. Pour y parvenir, il est possible d'utiliser des solutions de gestion de la configuration ou d'infrastructure as code afin de définir votre environnement de production, puis d'utiliser les mêmes configurations pour définir vos environnements de pré-production à des fins de développement, de test et de déploiement.

Concevoir en une fois et promouvoir les binaires

De nombreuses sociétés qui prétendent pratiquer le déploiement continu font la promotion du code source entre les équipes et environnements, en repensant le logiciel à chaque étape.  Il s'agit d'un contre-modèle de déploiement continu.  Chaque fois que vous repensez votre code source, le risque d'introduire et/ou de passer à côté d'erreurs augmente considérablement. Les différences potentielles dans les scripts de version, les environnements, etc. ne permettent pas de faire confiance aux tests et à la validation en amont.  L'approche correcte consiste à concevoir une seule fois et à promouvoir ensuite les binaires. Ainsi, chaque étape en aval repose sur la confiance dans la version créée lors des étapes précédentes.

Conclusion

L'intégration continue est le précurseur du déploiement continu. Ceux qui ne pratiquent pas l'intégration continue et le déploiement continu correctement ne profiteront pas de la valeur que ces processus représentent : délai de mise sur le marché plus court, avantage concurrentiel accru, logiciel de meilleure qualité et plus grande satisfaction des salariés.

A propos de l'auteur

Brian Dawson
DevOps Evangelist chez CloudBees