CI/CD

Késako ?

Pour commencer, que signifie exactement « CI/CD » ? Ce n’est pas bien compliqué et c’est le coeur même du monde DevOps. C’est parti pour des explications !

Continuous Integration

CI signifie « Continuous Integration » (ou Intégration Continue). L’idée est d’automatiser l’intégration de nos développements. Qu’est-ce que cela induit ? C’est simple !

• Chaque fois que le code source est modifié, le développeur le teste et le valide AVANT de le fusionner avec le code « propre ». En prenant pour exemple du code gestionné par Git, on pourrait obtenir la figure suivante (schématisée de façon simplifiée) :

• Par tests, on entend tests unitaires, tests d’intégration et tests statiques. L’idée générale est de valider non seulement le bon fonctionnement de l’application en cours de développement mais aussi et surtout sa non régression. On en profite également pour vérifier que les bonnes pratiques d’écriture de code ont bien été respectées. On sous-estime encore trop souvent l’importance des commentaires, de l’aération du code, des normes et références à suivre et cela conduit souvent à une perte de temps au niveau des évolutions et de la maintenance de l’application.
• Une CI bien construite renvoie un rapport détaillé au développeur, afin que ce dernier soit capable de retrouver et corriger les problèmes rencontrés.

Continuous Deployment

CD signifie « Continuous Deployment » (ou Déploiement Continu). Comme son nom l’indique, elle consiste à automatiser le déploiement des applications. L’idée est qu’une fois le code validé par les différents tests, une nouveau boucle d’automatisation s’occupe de le déployer, sans intervention humaine.

Note : on entend aussi parler de « Continuous Delivery » (ou Livraison Continue) pour la partie CD. Il s’agit simplement d’une forme plus « basique » deu Continuous Deployment. Dans ce cas, une intervention humaine est nécessaire avant le déploiement sur plateforme. Il s’agit souvent d’une vérification/validation.

Mise en place d’un pipeline CI/CD

Les outils

Pour pouvoir automatiser une infrastructure, certains outils sont incontournables. Dans l’univers des DevOps, il est essentiel de les connaître.

• Version Control System (ou Système de Contrôle de Version) : c’est probablement le premier outil à mettre en place pour faire des pipelines de CI/CD. Il permet de stocker des fichiers tout en maintenant un historique de modifications. Le plus connu d’entre eux est GIT.
• Plateforme d’automatisation : je ne pense pas qu’il soit utile de préciser l’importance d’un outil d’automatisation pour automatiser… Personnellement, j’en connais deux que j’ai utilisé pour différentes missions : GitLab CI/CD et Jenkins. Il existe beaucoup d’autres. Certains sont fournis par les Cloud Providers (AWS CodePipeline, Azure DevOps), d’autres sont des outils indépendants (GitHub Actions, Dagger, Travis CI).
• Environnements : dans toutes missions, qu’il y ait des pipelines de CI/CD ou non, il est important de définir plusieurs types d’environnements. Trois sont un minimum (mais tout dépend du projet, de la taille de l’équipe, des moyens financiers, de la politique de l’entreprise, etc.) :
  • Un environnement de développement destiné aux développeurs. Cet environnement est amené à être détruit, redéployé et à contenir des fonctionnalités en cours de développement. Elle ne doit surtout pas être prise pour un environnement de référence.
  • Un environnement de tests pour l’équipe de validation. Sur cette plateforme, une version figée de l’application est déployée et tous les tests sont lancés.
  • Un environnement de production qui n’accueille QUE les versions figées, vérifiées et validées. Cet environnement est destiné aux utilisateurs finaux. Les mises à jour doivent être strictement encadrées et aucun développement ne doit s’y faire.
  • D’autres environnements peuvent être créés selon le besoin. Dans une de mes missions, une plateforme appelée « pré-production » complétait la liste précédente. Elle contenait une version strictement similaire à la version en production, et permettait aux équipes de reproduire des bugs découverts et d’investiguer. Cela permettait de ne pas interrompre une campagne de tests en cours.
• Containeurisation : les microservices étant de plus en plus la norme, les outils permettant de les mettre en place sont devenus indispensables. Les plus célèbres sont Docker et Kubernetes en tant que gestionnaire de containers.

Et bien d’autres…

La partie précédente détaille les outils de base à inclure dans l’infrastructure de développement mais il convient de ne pas oublier les « à-côtés ».

• Sécurité : s’il y a bien un point qu’il ne faut pas négliger dans toute infrastructure, c’est bien la sécurité. Mettre en place des pipelines CI/CD nécessite d’utiliser de passer par des API. La gestion des comptes, mots de passe et services applicatifs autorisés à se connecter à vos différents outils doit être correctement réfléchie. Les Cloud Provider fournissent souvent des services tels que Cognito, Secret Manager pour AWS, et j’en passe. Vous trouverez tout ce qu’il faut en faisant quelques recherches en ligne.
• Registry : il s’agit de disposer d’une zone locale de stockage et partage d’images (Docker images, Harbor, JFrog Artifactory, etc.).
• Documentation : on en parle très peu mais pour moi, documenter les processus existants, les applicatifs, l’infrastructure est primordiale pour : les nouveaux arrivants dans le projet mais également l’équipe en place. Cette partie est souvent négligée et c’est bien dommage… Je considère qu’un bon ingénieur n’est PAS indispensable.

Il en existe encore d’autres. Tout se met en place au fur et à mesure de la réflexion architecturale. Ne partez pas tête baissée sans avoir tout préparé en amont !

Les avantages du CI/CD

Le CI/CD demande à se former sur plusieurs outils et, comme toute mise en place de nouveaux outils, il faut évidemment composer une architecture fonctionnelle sur papier AVANT de s’amuser au niveau technique. Ce n’est pas toujours facile à entendre mais c’est pourtant plus qu’indispensable.

Si vous avez encore un doute quand à la charge de travail que cela représente, je vous dirais simplement de cesser de penser à court terme. Car les avantages à long terme sont bien plus intéressants :

• Economie de temps
• Economie financière
• Amélioration du code (il est possible de créer des pipelines qui refusent tout push de code dans le gestionnaire de version si celui-ci ne respecte pas les bonnes pratiques ! J’adooooore les possibilités que cela représente !)
• Le développement de l’application et son déploiement sont bien plus rapides et ne nécessite pas d’intervention humaines (sauf si le code a expressément été codé pour)
• Supprime les silos développeurs vs intégrateurs <3
• Réduction des risques lors de la mise en production

Conclusion

Les pipelines CI/CD font bel et bien partie intégrante de la philosophie DevOps. Les connaître et les utiliser perpétuent l’éternel cliché du développeur fainéant et on aime ça !

Qui aime répéter en boucle les mêmes actions, taper les mêmes lignes de code ou lancer manuellement les mêmes tests durant plusieurs heures (voire plusieurs jours) ? Je ne sais pas pour vous, mais moi, ça me fatigue très vite ! Autant j’apprécie de tout faire manuellement au départ (ça me permet de comprendre tout ce qui se passe et d’être capable de le reproduire), autant, une fois la connaissance acquise, je préfère consacrer mon temps à des choses plus utiles, comme la poursuite de mes développements.

Chacun son truc, cela dit ! Mais je vous invite fortement à essayer si ce n’est pas déjà fait, ça en vaut le détour !