Comment passer au déploiement continu ?

Dans ce guide, nous supposerons que votre workflow d'intégration continue et de livraison continue est déjà en place, et que votre prochaine étape consiste à configurer votre pipeline de livraison continue.

Sten Pittet Sten Pittet

N'hésitez pas également à consulter notre tutoriel décrivant comment vous lancer avec le déploiement continu dans Bitbucket Pipelines.

« Personne ne touche à la production, je suis sur le point de livrer ! »

Cette phrase vous est peut-être familière. Le déploiement en production peut s'avérer un exercice risqué et coûteux qui nécessite parfois de mettre en attente tous les développements. Les cycles de livraison sont donc lents et les changements stagnent dans l'environnement de développement. C'est le début d'un cercle gênant (et vicieux) dans lequel plus des commits sont effectués dans le dépôt, plus des risques sont introduits dans le prochain déploiement en production, et moins votre équipe est susceptible d'effectuer cette livraison.

Le déploiement continu permet de résoudre ce problème en envoyant automatiquement en production chaque changement pushé vers le dépôt principal. C'est une approche radicale, très différente de celle qui consiste à passer des jours à préparer et à contrôler chaque version ; néanmoins, le déploiement continu offre plusieurs avantages :

  • Les versions deviennent plus petites et plus faciles à comprendre.
  • Personne n'est tenu d'arrêter son travail pour effectuer un déploiement, parce que tout est automatisé.
  • La boucle de feedback avec vos clients est plus rapide : les nouvelles fonctionnalités et améliorations vont directement en production lorsqu'elles sont prêtes.

Il peut être très décourageant de passer de versions approuvées au déploiement continu. Ce guide est là pour vous aider à faire la transition. Nous aborderons les notions fondamentales afin que vous puissiez vous lancer au plus vite et commencer à accélérer votre cycle de livraison.

Déploiement continu et livraison continue

Si vous souhaitez implémenter un pipeline de déploiement continu, la livraison continue est le point de départ idéal. Ces deux pratiques sont similaires, mais diffèrent dans leurs approches des déploiements de production. En cas de livraison continue, chaque changement pushé vers le dépôt principal est prêt à être livré, mais le processus de mise en production nécessite toujours une approbation humaine. En déploiement continu, la mise en production est effectuée automatiquement pour chaque changement qui réussit la suite de tests.

Livraison continue et déploiement continu

Avant de commencer à livrer automatiquement les changements apportés à la production, vous devez avoir une bonne culture d'intégration continue (CI), et il est fortement recommandé de commencer par la livraison continue. Vous pouvez en savoir plus sur les deux pratiques dans les articles ci-dessous :

Passer de la livraison continue au déploiement continu

Mettez l'accent sur une culture d'intégration continue

Le déploiement continu repose sur une grande culture d'intégration continue. La qualité de votre suite de tests déterminera le niveau de risque de votre version, et votre équipe devra faire de l'automatisation des tests une priorité pendant le développement. Cela impliquera d'implémenter des tests pour chaque nouvelle fonctionnalité et d'ajouter des tests pour toutes les régressions découvertes après la livraison.

La réparation d'un build endommagé pour la branche principale devrait également être la priorité. Sinon, vous vous exposerez aux mêmes risques que ceux que vous avez rencontrés avant d'adopter un déploiement continu : les changements s'accumulent dans l'environnement de développement, et les développeurs ne sont pas sûrs que leur travail est terminé, car ils ne savent pas si leurs changements ont réussi les tests d'acceptation.

Assurez-vous d'avoir une bonne couverture de test (et de bons tests !)

Commencez à utiliser des outils de couverture de test pour vous assurer que votre application est correctement testée. Une couverture de 80 % représente un bon objectif.

Ne confondez pas une bonne couverture avec de bons tests. Vous pourriez avoir une couverture de test de 100 % avec des tests qui ne mettent pas vraiment votre base de code à l'épreuve. Pendant les revues de code, assurez-vous de consacrer du temps à vérifier la façon dont les tests sont écrits et n'hésitez pas à signaler des lacunes dans la couverture ou toute faiblesse des tests. Votre suite de tests filtre les envois à la production, assurez-vous qu'elle joue bien son rôle.

Adoptez une surveillance en temps réel

Si vous prévoyez de déployer chaque commit en production de façon automatique, vous devez vous assurer de disposer d'un bon moyen d'être alerté en cas de problème. Parfois, un nouveau changement n'interrompra pas immédiatement la production, mais aura des conséquences sur la consommation de l'UC ou l'utilisation de votre mémoire, qui risquent d'atteindre un niveau dangereux. C'est pourquoi il est intéressant de mettre en place une surveillance en temps réel sur vos serveurs de production, afin de pouvoir suivre les anomalies qui apparaissent dans les indicateurs.

Des outils comme Nagios ou des services comme New Relic peuvent vous aider à suivre les mesures de performance de base et vous alerter en cas de perturbation de vos systèmes.

Passez en revue les tests réalisés après le déploiement

Après chaque déploiement en production, vous devez réaliser quelques smoke tests simples pour vous assurer que l'application est opérationnelle.

Assurez-vous que ces tests font plus que simplement contacter une page statique, en attendant une réponse de réussite. Une bonne pratique consiste à mettre en place un test qui exige que tous vos services de production (base de données, microservices, tierces parties…) fonctionnent correctement.

Faites travailler votre équipe de QA en amont

Étant donné que chaque commit est désormais directement en production, vous ne disposez pas d'un tampon traditionnel pour que votre équipe d'assurance qualité examine et approuve les nouvelles fonctionnalités. À la place, elle devra travailler en étroite collaboration avec le responsable produit et l'équipe de développement afin de définir les risques associés aux nouvelles améliorations.

Il s'agit d'une excellente opportunité pour l'équipe d'assurance qualité, car elle entraînera une meilleure qualité des versions. Avec un déploiement continu, votre équipe sera naturellement encline à avoir une bonne couverture de tests de la base de code. Ne pas disposer d'une telle couverture expose à des interruptions fréquentes en raison de bugs s'étant glissés en production où ils sont découverts par vos utilisateurs.

Supprimez les notes de version traditionnelles

Avec le déploiement continu, il est plus difficile pour vous de suivre le rythme des versions, et c'est une bonne chose ! Votre objectif devrait être des déploiements en production quotidiens, voire plusieurs déploiements par jour. Il peut s'agir de correctifs de bugs, de petites améliorations, de nouvelles fonctionnalités… peu importe. Dès qu'un développeur termine son travail, ce travail devrait être exécuté en production en quelques minutes.

Dans ce nouveau monde, il n'est plus possible d'écrire des notes de version qui seront envoyées à vos clients avec chaque nouvelle version. Adoptez plutôt ce nouveau flux et limitez vos annonces aux fonctionnalités clés qui comptent pour vos clients. Les rapports de bugs et les petites demandes d'amélioration peuvent simplement être traités dans votre système de ticket. Jira, par exemple, peut tenir informé tous les observateurs d'un ticket dès que vous le fermez ou le mettez à jour.

Une approche différente pour les nouveaux projets : déployer en production avant le codage

Si vous vous lancez dans une nouvelle base de code, vous pouvez faire quelque chose d'intéressant. Vous pouvez commencer par créer votre pipeline de déploiement continu avant que tous les clients et les fonctionnalités soient prêts (contrairement au développement piloté par les tests). Au début, vous livrerez une plateforme vide. Ensuite, au fur et à mesure que le développement progresse, de nouvelles capacités commenceront à apparaître automatiquement. Il vous suffit de garder votre environnement de production fermé jusqu'à ce que vous soyez prêt à l'ouvrir à vos clients.

Cette approche peut sembler contre-intuitive au début. Mais c'est un moyen facile d'éradiquer le stress en passant d'une approbation manuelle à un déploiement continu et à la production. C'est également un excellent moyen de vous assurer que vous disposez d'une bonne couverture de test et d'une culture d'intégration continue au lancement, car elles sont nécessaires pour un déploiement continu.

Développez vos connaissances et partagez votre expérience !

Nous comprenons qu'il peut-être difficile de sauter le pas et de passer au déploiement continu. Tout d'un coup, les vannes sont ouvertes, et le code est directement livré aux clients en quelques minutes ou en quelques heures. (Aaaaaah !) Il est donc important d'investir dans des tests et des automatisations qui vous donnent confiance en vos builds. Ce sera facile si votre base de code est nouvelle, mais cela peut nécessiter l'adoption d'une stratégie différente pour une base de code existante complexe.

Commencez petit et développez vos connaissances et votre expérience en matière de déploiement continu. Une fois que vous y arriverez pour un projet, il sera plus facile de reproduire votre réussite dans d'autres parties de votre organisation.