Aller au contenu
Korben, roi d’internet, logo bébé avec des lunettes en mode thug life

Les avantages merveilleux du CI / CD pour les dev

— Article en partenariat avec Talent.io —

Aujourd’hui les amis, nous allons parler d’un sujet très cher au Devops : Le CI/CD !

Pour ceux qui auraient zappé ces 10 dernières années, le CI/CD est une méthode de développement qui permet de publier des mises à jour de votre code à tout moment sans impacter ce qui est en production. C’est donc parfait lorsqu’on a besoin de mettre en place des cycles de développement plus rapide avec des modifications de code quotidiennes.

En ce qui concerne la signification, CI veut dire « Intégration Continue » et CD, « Déploiement Continu ». C’est très demandé dans les entreprises actuelles et en tant que développeur ou devops, c’est un sujet que vous devez connaître surtout si vous avez prévu de changer de travail pour quelque chose qui vous correspond plus.

Si vous souhaitez être plus proche de chez vous voire en télétravail, avoir un meilleur salaire ou tout simplement travailler sur des projets plus intéressants, je vous invite à vous créer un compte sur la plateforme talent.io. Ça se fait en quelques clics et vous recevrez ensuite des offres de la part d’entreprises qui correspondent à vos critères et qui affichent le salaire d’entrée de jeu ! talent.io c’est LE moyen le plus simple et le plus rapide de trouver votre prochain job tech. Les inscrits trouvent leur emploi en 20 jours en moyenne.

L’intégration Continue

Ce qu’on appelle Intégration Continue (CI) consiste pour les développeurs à tout simplement fusionner avec la branche master, l’ensemble de leurs modifications et cela autant de fois qu’ils le souhaitent

Ainsi, une équipe de développeurs peut travailler simultanément sur le même projet. Le fait d’intégrer une équipe de développeur dans un processus CI/CD permet de s’assurer que le code est testé, correctement formaté et compatible avec l’existant avant de le déployer.

Chacune de ces fusions de code va alors déclencher automatiquement une séquence qui « construire » (build) et tester le code. Ainsi, à chaque ouverture d’une pull request ou à chaque modification du code, le serveur git envoie une notification au serveur d’intégration continue. Ce dernier va alors cloner le dépôt, effectuer les checkouts nécessaires sur la branche source pour enfin la fusionner avec la branche master. Puis le script de build est alors lancé. Cette étape permet ainsi de valider que le code est sûr et respecte les bonnes pratiques, mais également d’automatiser le chargement des dépendances, l’installation des outils nécessaires à l’application et bien sûr la compilation si besoin.

Exemple de script dans l’éditeur de pipeline de Gitlab

La phase de build

Cette phase de build vérifie que l’application, selon le code qui a été commité, peut se qualifier pour les tests ultérieurs.

Cela consiste à « construire » l’application. Avec des langages compilés, ça signifie obtenir un binaire opérationnel alors que sur les langages interprétés, cela consiste à valider la présence des dépendances et des outils nécessaires pour construire l’application. L’objectif ici est d’avoir quelque chose qu’on puisse lancer et tester. Cela peut donc être un binaire, un programme d’install, une image docker, un site web…etc.

La phase de test

La seconde étape consiste à analyser le code sous différents aspects à l’aide d’outils de tests automatisés. C’est une étape qui lorsqu’elle est faite manuellement, est boudée par les développeurs qui la trouvent chronophage et ennuyeuse. On pourrait bien sûr déléguer les tests à d’autres personnes, mais cela déconnecte les développeurs de l’ensemble du projet sans parler du fait que les testeurs vont passer leur temps à les déranger.

Les étapes de validation

Ainsi durant cette phase de test, le linting qui consiste à vérifier le code pour détecter les erreurs programmatiques et stylistiques. Cela permet de s’assurer une certaine homogénéité dans le code.

La qualité du code et de ses fonctions est également évaluée et de nombreuses mesures comme le nombre de lignes, la documentation ou la complexité du code sont prises en compte pour déterminer les endroits dans le projet où le code peut être amélioré.

La sécurité du code est également prise en compte à l’aide d’outils d’analyses qui partent à la recherche des risques de vulnérabilités dans le code lui-même et ses dépendances.

L’accès aux logs

Tout cela se fait durant un laps de temps assez rapide (moins d’une dizaine de minutes) selon les ressources machines disponibles et une fois que la séquence est terminée avec succès, cela signifie que la Pull Request est autorisée et on peut alors passer à la phase de déploiement.

Évidemment, si la séquence est stoppée à cause d’une erreur, la fusion du code est stoppée et un rapport est généré pour permettre aux développeurs de résoudre rapidement le souci. Le CI permet ainsi de travailler par petites itérations et les bugs peuvent ainsi être corrigés plus rapidement.

Vient ensuite une phase « release » qui consiste à packager l’application pour son déploiement ou sa distribution en y intégrant le code de l’application, les scripts d’installation, les dépendances et autres bibliothèques, la documentation, les métadonnées et bien sûr la licence.

Cette version packagée de l’application est alors disponible pour être distribuée ou publiée sur le serveur et servir de point de départ à une configuration des éléments tiers comme la base de données. Si on s’arrêtait à cette étape, on parlerait alors de « livraison continue » (Continuous Delivery), c’est à dire s’assurer que le code est en permanence déployable.

Mais avec le déploiement continu, comme avec talent.io, on va un peu plus loin. D’ailleurs pensez bien lorsque vous renseignerez votre profil talent.io à vous démarquer en faisant ressortir vos points forts comme la maîtrise des concepts CI/CD et vos éléments différenciant pour que les entreprises qui recrutent s’arrêtent sur votre profil.

Le déploiement continu

La phase CD (Déploiement Continue) permet de déployer cette release sur le serveur de destination soit directement après chaque pull request, soit en respectant un calendrier de mise en prod ou sur action humaine uniquement. Ainsi, chaque changement qui arriver à passer toutes les étapes de validation (CI) peut alors finir en production, et cela sans aucune intervention humaine.

C’est donc un excellent moyen d’accélérer la mise en production des nouveautés et permet aux développeurs de se concentrer sur l’écriture de code plutôt que d’organiser des journées de mises en production après des mois de travail à l’aveugle.

Lorsque vous aurez trouvé l’entreprise de vos rêves grâce à talent.io, je compte sur vous pour mettre du CI/CD en place afin de soulager votre équipe ou vous même.

Les outils

Pour faire du CI/CD, il existe des dizaines de solutions commerciales dont voici les plus connues et utilisées :

  • Jenkins est super populaire, car totalement libre et gratuit et permet de décrire des pipelines de construction avec le langage Groovy. Il offre ainsi plus de flexibilité, mais demande un peu plus de compétences techniques.
  • GitHub Actions, cet outil de CI/CD proposé sur le site GitHub et son équivalent pour les entreprises, permet de construire ses pipelines à l’aide d’une configuration YAML.
  • Gitlab CI/CD est semblable à Github Actions. Il est capable de pointer de manière assez spécifique vers les tests qui ont échoué, ce qui permet un debug plus rapide.
  • Enfin, Travis CI totalement dans le cloud permet de monter ses routines CI/CD sans aucune configuration complexe. Et comme il est compatible gratuitement avec Github, Bitbucket ou encore Gitlab, vous pouvez également l’utiliser pour vos projets open source ouvert.

Conclusion

Vous l’aurez compris, il y a de nombreux avantages à mettre en place une procédure CI / CD. En procédant par petites étapes, et en multipliant le nombre d’itérations, on réduit ainsi la probabilité d’erreur et la quantité de travail nécessaire à l’intégration des changements dans l’application. Au contraire, travailler dans de longues boucles de rétroaction est beaucoup plus risqué pour le projet et le temps de travail est plus difficile à estimer.

Le fait d’automatiser toutes ces étapes d’intégration soulage fortement les développeurs des tâches répétitives et permet d’éviter bon nombre d’erreurs humaines à l’aide des tests automatisés effectués à chaque livraison de code. Cela se fait d’ailleurs en toute transparence avec un accès rapide aux logs et il devient très simple de comprendre d’où provient l’erreur.

Il y a donc une meilleure productivité de la part des développeurs, des releases plus fréquentes et une augmentation de la qualité et de la sécurité de ce qui est produit grâce à la standardisation des tests.

Si vous ne l’avez pas encore mis en place dans votre entreprise, je vous recommande vivement d’essayer l’approche CI/CD. Cela vous soulagera sur bien des aspects, notamment en ce qui concerne les tests et l’ensemble des tâches rébarbatives et vous pourrez enchaîner les déploiements dans la joie.

Pensez également à vous créer un profil gratuitement sur la plateforme talent.io, que ce soit pour trouver votre nouvel emploi ou simplement rester à l’écoute du marché. Déjà plus 6 000 développeurs, devops et autres profils tech ont été recrutés grâce à talent.io, alors pour quoi ne pas tenter ?


Les articles du moment