Par Gologic en collaboration avec Alexandre Couëdelo.
L’intégration continue (CI) et le déploiement continu (CD) sont les pratiques clés que vous avez besoin de maîtriser pour réussir votre transformation et adopter l’approche DevOps.
Réussir à implémenter le déploiement continu c’est le Saint Graal. Cela veut dire que votre processus est tellement mature et automatisé que chaque changement de code est validé et envoyé en production sans intervention humaine. De l’autre côté, l’intégration continue est la base de l’approche DevOps. Les développeurs sont capables de modifier le code d’une application fréquemment et de vérifier que leurs modifications s’intègrent proprement avec celles de leurs collègues.
Pour passer de l’intégration continue au déploiement continu vos équipes vont aussi devoir apprendre un certain nombre de pratiques telles que les tests en continu (CT), la livraison continue (CD), le monitoring et l’alertage.
L’architecture CI/CD
Cependant, ce changement est plus complexe qu’il n’y paraît. Construire un pipeline CI/CD tel qu’illustré dans les livres ou sur internet n’est pas suffisant. Pour que votre organisation réussisse à se transformer vous devez mettre en place l’architecture et les pratiques qui permettront aux « Dev » et « Ops » de pleinement collaborer.
D’un côté, les « Ops » vont devoir définir une infrastructure dans laquelle la culture DevOps peut grandir. De l’autre côté, les « Dev » doivent apprendre à travailler avec l’approche « fail-fast » (c’est-à-dire échouer au plus tôt).
Dans cet article, vous allez apprendre ce dont vous avez besoin pour préparer votre organisation à utiliser l’approche CI/CD.
Définir l’architecture cible
Du point de vue des opérations, mettre en place le CI/CD implique de redéfinir l’infrastructure. En effet, vous aurez besoin de quelque chose de plus collaboratif dans lequel les développeurs peuvent également opérer des applications en production.
L’infrastructure libre-service
Le succès du DevOps est grandement soutenu par l’infrastructure en libre-service. Vous avez sûrement déjà entendu parler de IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service). Tous ces outils mis à disposition par des fournisseurs externes aident vos équipes à gérer leurs infrastructures simplement grâce à des APIs ou des outils de gestion des configurations.
En plus des outils externes, vous aurez besoin de construire votre propre libre-service interne, sur lequel les équipes peuvent construire de nouvelles applications de manière autonome. Bien souvent, cela se caractérise par des « templates » mis en place par les équipes d’opérations pour faciliter un développement rapide, mais avec un contrôle sur les coûts et la sécurité.
Éléments de l’infrastructure
Votre nouvelle infrastructure devrait comporter les éléments suivants :
1. Des microservices : gérés par les développeurs. « You build it you run it. »
2. Des ressources : composants d’infrastructure requis par un microservice, géré par des développeurs, basé sur un « template » fourni par les équipes d’opérations.
3. Des services partagés : utilisés à la fois par « Dev » et « Ops » pour gérer le cycle de vie logiciel (code repository, CI/CD toolchain, monitoring).
4. La plateforme : couche d’abstraction pour faciliter l’intégration et l’opération des applications (ex. : Kubernetes).
5. L’infrastructure : la partie submergée de l’iceberg avec les machines et le réseau.
Avant de vous lancer, identifier les éléments manquant pour adopter l’approche infrastructure en libre-service. Évaluer les outils existant pour voir s’ils s’intègrent dans le nouveau modèle. Mettez au défi vos fournisseurs de service pour voir s’ils peuvent s’intégrer avec le modèle cible (API, gestion des configurations). Sinon, rechercher de nouveaux fournisseurs de service, cela vous épargnera bien des efforts.
Mettre en place une boucle de rétroaction
avec l’approche « fail-fast »
Du côté logiciel (« Dev »), tout commence avec l’adoption du principe fail-fast.
L’approche « fail-fast » implique que vous mettiez en place des étapes de validation automatique tout au long du processus. Si une validation échoue, l’équipe responsable doit retravailler le code jusqu’à ce que la validation passe. Pour les équipes peu familières avec ce mode de fonctionnement, la transition peut être frustrante. Par conséquent, vous devez vous préparer à un processus itératif dans lequel vous n’automatisez qu’une petite partie à la fois, jusqu’à ce qu’il soit fiable et robuste.
Toujours commencer par mettre en place l’intégration continue. Une fois que le code est disponible dans le dépôt, il est compilé et testé unitairement. Si le code ne respecte pas les critères de qualité (couverture de tests unitaires, détection des bogues, audit de sécurité), l’équipe responsable est informée et le code ne peut pas aller plus loin tant que les erreurs ne sont pas corrigées.
Les tests en continu
La deuxième étape consiste à mettre en place la base pour les tests en continu (CT). Dans un premier temps, n’automatiser que les tests du chemin critique ou répétitif. Il est important de simplifier le processus au maximum avant d’automatiser de plus en plus de tests. Sinon vous risquez de perdre du temps sur un processus déjà défectueux.
Ensuite, améliorer le monitoring et les alertes. La meilleure approche pour commencer c’est de mettre en place des notifications sur toutes les erreurs sans exception (pendant les heures de bureau). Avec le temps, les équipes vont apprendre à mieux gérer leurs erreurs dans le code et les alertes deviendront utilisables pour supporter la production 24/7.
Enfin, raffiner le processus jusqu’à ce que votre niveau de confiance vous permette de déployer en production automatiquement (déploiement continu). Pour atteindre votre but, essayez de supprimer les goulots d’étranglement quand vous les rencontrez. Une approche qui marche bien est celle du « shift left. » Elle consiste à automatiser toutes les étapes que vous gardiez pour la fin et qui ralentissaient le processus, et de les placer le plus tôt possible dans votre pipeline afin de renforcer l’approche « fail-fast ».
En résumé
L’intégration continue (CI) et le déploiement continu (CD) sont les deux pratiques nécessaires à votre organisation pour atteindre des livraisons applicatives rapides et fiables.
Afin de réussir, vous devez insister sur deux choses :
- Rassembler « Dev » et « Ops » autour d’une architecture qui prône la collaboration (libre-service).
- Mettre en place l’approche « fail-fast » ; puis lentement mais sûrement, vous dotez des capacités nécessaires pour atteindre le déploiement continu.
Obtenez des conseils d’experts du DevOps
Vous désirez créer votre chaîne de déploiement logicielle automatisée et accélérer vos livraisons ? Les conseillers DevOps de Gologic peuvent vous aider à mettre en place des pipelines as code, incluant le développement, l’intégration, les tests, la livraison et le déploiement continus (CI/CD). Explorez nos services ou contactez-nous pour en apprendre davantage sur notre approche stratégique.
Par Gologic en collaboration avec Alexandre Couëdelo.
