Le « Continuous Delivery » pattern (CD) est le principal bénéficiaire du « Continuous Integration » pattern (CI) que nous n’aborderons pas dans ce livre blanc. Mais en quelques mots, le CI correspond aux pratiques DevOps qui vont permettre l’intégration des changements dans le code source d’un logiciel de la part d’un ou plusieurs développeurs en s’assurant que d’éventuels critères de qualité (tests d’acceptance, couverture du code) soient respectés. Ce pattern CI va en général s’achever par la construction d’un livrable qui sera alors disponible pour le pattern CD.
Comme on peut le voir dans le cadre du pattern CI, l’automatisation va être indispensable afin d’effectuer le plus rapidement possible des tâches redondantes de tests et de contrôle qualité. Cette automatisation va elle aussi être au centre du pattern CD. En effet, c’est cette dernière qui va permettre de réduire le risque au maximum lors d’étapes aussi cruciales que celle du déploiement.
Dans le cadre de systèmes reposant sur l’architecture microservice, les livrables vont bien souvent prendre la forme d’images Docker qui vont, par exemple, permettre d’instancier des pods dans le cadre de Kubernetes ou bien de conteneurs dans le cadre d’une installation avec docker-compose.
Dans un même temps, on va vouloir effectuer des déploiements sur des environnements variés comme des environnements d’intégration, de tests de charge, de préproduction ou production. Il va alors être essentiel de s’assurer que les images Docker n’embarquent aucune configuration propre à un environnement car cela va permettre de rendre ces images Docker le plus « portables » possibles. La mise en place du pattern d’ « Externalized Configuration » va alors être particulièrement pertinent.
On pourra alors aisément réutiliser ces mêmes images peu importe l’environnement et aucune étape de build ne sera alors nécessaire lorsque l’on doit passer d’un environnement à l’autre.
L’autre aspect essentiel du pattern CD concerne la disponibilité de l’application. En effet, si on automatise le déploiement d’une application on souhaite minimiser voire réduire à zéro la période d’indisponibilité d’une application lors d’un déploiement. Il s’agit alors de mettre en place des stratégies telles que le « Blue Green Deployment » :
Chez SpikeeLabs, nous avons décidé de généraliser l’usage de GitLab CI/CD sur l’ensemble de nos projets. GitLab CI/CD, comme son nom l’indique, est avant tout un gestionnaire de versions de code source supportant le protocole GIT. Son mécanisme de pipeline le rend particulièrement attrayant lorsqu’il s’agit d’automatiser des actions en réaction à des évènements sur le code source : merge request validée, tag posé… On va s’en servir pour automatiser les actions d’intégration (aspect CI) mais aussi pour les actions de livraison (CD). Ces pipelines peuvent eux-mêmes être versionnés et ainsi être réutilisés pour des projets similaires. L’usage de GitLab CI/CD nous a permis de remplacer le duo Git/Jenkins utilisé par le passé. Par ailleurs, la gestion des rôles permet de limiter les actions réalisables sur GitLab et ainsi on pourra par exemple restreindre le déclenchement d’une livraison à un utilisateur ayant le rôle « maintainer ». Il est ainsi possible de mettre en place des déploiements entièrement automatisés et sécurisées sur de multiples environnements.
"10 patterns à connaitre pour une architecture microservice"