CI/CD, pour continuous integration / continuous delivery et/ou continuous deployment est aujourd’hui une pratique courante dans le monde du développement logiciel. Outil DevOps, il permet de livrer/déployer de manière continue et automatisée un produit, et de simplifier la relation entre le monde du développement et celui de l’exploitation.
Vous voulez en savoir plus sur le fonctionnement de l’intégration continue et du déploiement continu ? Nous vous expliquons tout dans cet article !
CI/CD, la définition
Pour rentrer un peu plus dans les détails, le CI/CD permet de builder, tester, livrer et/ou de déployer de manière automatique un produit développé. Cela fait donc le lien entre les équipes de développement et d’exploitation, chargée respectivement de créer le produit, et d’exploiter et de déployer ce produit. C’est en cela une pratique DevOps.
Voyons un peu plus en détails les trois composantes du CI/CD.
L’intégration continue
L’intégration continue consiste à commit et merge le code des développeurs sur une même branche le plus régulièrement possible. L’idée est ici de s’assurer que la fusion des codes ne provoque pas de breaking changes, en forçant les merges une ou plusieurs fois par jour.
Le but du CI est de se rendre compte au plus tôt lorsqu’il y a bug, des régressions ou des conflits, et ainsi de pouvoir les résoudre au plus vite pour éviter la dette technique.
L’intégration continue comprend, et c’est là aussi un point clé, une phase de tests en amont. Nous pourrions découper le workflow de la façon suivante :
- Les tests (d’intégration, notamment) sont lancés en local sur la machine du développeur avant ou au moment du commit ;
- Le code est compilé sur le serveur, ce qui permet de détecter les éventuelles erreurs de merge ;
- Le code est de nouveau soumis aux tests sur le serveur pour s’assurer qu’il n’y ait pas de problème.
On passe ensuite à l’étape suivante : la livraison (ou le déploiement) continue.
La livraison continue
Une fois toutes les étapes de l’intégration continue effectuées, nous pouvons passer à celle de la livraison. La livraison continue (ou continuous delivery) consiste à valider le build créé à l’étape CI via d’autres tests (d’acceptation, validant le fonctionnel du produit), puis à mettre à disposition un livrable déployable immédiatement.
Par exemple, dans le cas du développement d’une application Android, si l’intégration effectue le build et les tests, l’étape de livraison continue pourrait créer un bundle signé prêt à être déployé sur les stores ou pour les testeurs.
Le déploiement continu
Le déploiement continu, ou continuous deployment, est très proche de la livraison continue : on crée là aussi un livrable. La différence, c’est que le déploiement est cette fois automatique. En reprenant notre exemple d’application Android, nous pourrions imaginer qu’elle soit uploadée et envoyée aux bêta testeurs sans action humaine.
Les avantages et inconvénients du CI/CD
Maintenant que nous savons ce qu’est, dans le principe, le CI/CD, parlons un peu des avantages et inconvénients de cette méthode DevOps.
Les avantages de la méthode
Si le concept de CI/CD convainc de plus en plus d’équipes de développement, ce n’est pas pour rien ! Cette méthode présente en effet des avantages certains :
- Les bugs et régressions sont détectés presque immédiatement ;
- Une version prête à l’emploi et à jour est disponible sans interruption ;
- Les utilisateurs finaux ayant accès très régulièrement aux dernières versions, ils peuvent faire des feedbacks en temps réel.
En cela, l’utilisation de CI/CD rend le développement plus performant, et les cycles de construction/release plus rapides, plus sûrs.
Les inconvénients de la méthode
Toutefois, cette pratique n’est pas dénuée d’inconvénients ; elle serait sinon utilisée partout. Citons parmi ceux-ci :
- Un temps de mise en place potentiellement élevé, et qui requiert un savoir-faire et de l’expérience ;
- La création et le développement de tests (d’intégration) en continu, sans interruption ;
- La mise en place d’un serveur CI/CD et la création des scripts du pipeline ;
- Le déploiement continu n’est pas recommandé dans tous les cas (si on ne doit absolument pas avoir de coupure de service, même le temps du déploiement, mieux vaut gérer manuellement les déploiements).
Tous ces éléments, notamment la mise en place du pipeline et le développement des tests, font que le CI/CD peut être difficile à intégrer. Certaines entreprises ont des contraintes budgétaires et/ou temporelles qui limitent l’utilisation de ces méthodes (bien que sur le long terme, elles peuvent faire gagner du temps et de l’argent).
La mise en place d’un pipeline CI/CD
Nous avons vu théoriquement tous les éléments de CI/CD, leurs avantages et inconvénients, mais comme cela se passe, concrètement ? Comment crée-t-on un pipeline CI/CD ? C’est ce que nous allons expliquer dans cette section.
Le pipeline en détails
Pour expliquer clairement le fonctionnement d’un pipeline d’intégration/déploiement continu, partons de ce schéma, tiré de la documentation de GitLab, qui met à disposition un service CI/CD (GitLab CI/CD).
La partie intégration continue est située dans le bloc “Verify”, et nous voyons qu’elle a les rôles suivants :
- La vérification de la qualité du code ;
- Les tests (de performances, d’intégration) ;
- La vérification du container et des dépendances.
La partie CD, dans le bloc “Release”, explique le fonctionnement du déploiement et de la livraison continue. Dans les deux cas, le produit est déployé en production ; mais ce déploiement est manuel dans le cas de la livraison continue.
Quelques exemples d’intégration devops de CI/CD
Nous l’avons évoqué, certains fournisseurs permettent la mise en place de l’intégration/déploiement continu relativement facilement.
Le cas de GitLab
C’est notamment le cas de GitLab, célèbre logiciel libre de forge, dont nous avons déjà parlé. Expliquons un peu plus en profondeur son fonctionnement.
GitLab CI/CD fonctionne sur la base d’un fichier yml (nommé .gitlab-ci.yml, disposé à la racine du répertoire), devant contenir les instructions à exécuter lors du passage dans le pipeline.
Voici un exemple de ce fichier, pris de la documentation GitLab :
build-job:
stage: build
script:
- echo "Hello, $GITLAB_USER_LOGIN!"
test-job1:
stage: test
script:
- echo "This job tests something"
test-job2:
stage: test
script:
- echo "This job tests something, but takes more time than test-job1."
- echo "After the echo commands complete, it runs the sleep command for 20 seconds"
- echo "which simulates a test that runs 20 seconds longer than test-job1"
- sleep 20
deploy-prod:
stage: deploy
script:
- echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
Bien sûr, le mode CI/CD de GitLab est bien plus puissant que cela, cet exemple ne fait qu’afficher du texte dans une console au moment des commits. Pour en savoir plus, mieux vaut se référer directement au site officiel de GitLab.
GitLab CI/CD est gratuit jusqu’à 400 minutes d’utilisation du pipeline par mois, au-delà, il faudra choisir un plan payant, ou payer l’utilisation de la fonctionnalité CI/CD en add-on.
Avec l’utilisation d’Amazon Web Service ou Azure
Il est également possible d’utiliser des pipelines CI/CD via des fournisseurs cloud tels que AWS ou Azure.
Ces fournisseurs, permettant notamment de faire des applications serverless, mettent en effet à disposition des fonctionnalités d’intégration continue et de livraison continue.
Côté Amazon, nous avons AWS CodePipeline, qui coûte $1 USD par pipeline actif, et côté Microsoft, nous retrouvons Azure Pipelines, service qui offre gratuitement 1 800 minutes d’utilisation d’un pipeline par mois, puis $40 pour chaque pipeline, avec utilisation illimitée.
Les deux permettent des intégrations avec des services externes, notamment avec GitHub.
Aller plus loin dans la vérification du code
Ce que nous pouvons retenir de cet article, c’est que le CI/CD a pour objectifs principaux de garantir une haute qualité du code, la résolution rapide des bugs et une mise en production en un temps record.
Mais ce n’est pas le seul outil qui permet d’optimiser le code, loin de là ! Si on veut aller plus loin dans la vérification du code, et ce en amont du commit (avant donc la phase CI), on peut par exemple utiliser un linter.
Ces outils permettent en effet l’analyse en temps réel du code, pour en faire ressortir les erreurs et incohérences. Par exemple pour JavaScript, il existe JSLint, outil auquel nous avons consacré un article complet, à retrouver ici.
Avez-vous déjà eu à utiliser des pipelines CI/CD dans vos projets ? Si oui, quels sont vos retours d’expérience ? Dites-nous tout en commentaire !
