L'intégration continue et le déploiement continu (CI / CD), parlons-en

Au même titre que Github ou Docker, la plupart des développeurs de nos jours ont déjà dû tomber sur cet amas de lettres étranges.

Et bien aujourd’hui on va vous dire ce que ça signifie et surtout ce que c’est et à quoi ça sert ! 😀

L’intégration continue (CI, pour Continuous Integration) et le déploiement continu (CD pour Continuous Deployment) sont des étapes dans le versioning de votre code. D’ailleurs si vous voulez qu’on vous explique le versioning, Git et tout ce qui s’en suit dans un autre article, n’hésitez pas à nous le dire ! 😁

L’intégration continue

Cette étape consiste donc à effectuer une batterie de tests lorsque vous envoyez votre code vers votre dépôt afin de vérifier que tout est en ordre sur plein de points. Ça peut être un audit de sécurité au niveau des dépendances de votre projet, un check rapide de votre code au niveau de son écriture et des bonnes pratiques, ou bien des tests unitaires/fonctionnels.

"Mais c’est bien gentil mais ça va rallonger le temps de mes git push ton truc ?!"

Alors oui. Mais non. Au même titre que d’écrire vos tests unitaires et fonctionnels vous prend du temps sur le moment. Cela vous en fait gagner beaucoup par la suite pour savoir si quelque chose ne va pas dans le code. Et accessoirement ne pas tout casser si vous faites un push en prod 😀.

Et en plus, votre push en lui-même prendra autant de temps qu’avant puisque les tests vont se faire directement sur votre dépôt côté serveur, pas dans votre console.

L’intérêt d’exécuter tout un processus au moment du dépôt c’est qu’il va se faire automatiquement par votre outil (Github, Gitlab, etc) via ce qu’on appelle des pipelines.

Celles-ci vont s’exécuter dans un ordre que vous aurez vous-même défini et avec des étapes bloquantes ou non (selon votre choix).

Par exemple, imaginons que dans un projet Symfony vous souhaitez vérifier avant chaque déploiement que les dépendances utilisées dans votre projet par Composer soient à jour et sans faille de sécurité.

Vous pouvez dans ce cas utiliser un outil tel que : local-php-security-checker disponible ici dans une image Docker prévue pour la CI/CD

"Ok mais où est-ce que je lance cet outil et comment je paramètre tous les scripts qui vont se lancer à chaque mise en prod ?"

Grâce à un simple fichier qu’il faudra nommer .gitlab-ci.yml (dans le cas de Gitlab) dans lequel vous aller définir le nom de chaque étape (stage) ainsi que l’ordre et si elle sera bloquante ou non en cas d’échec.

Voilà, si vous ajoutez ce petit fichier à la racine de votre projet Symfony il créera automatiquement une Pipeline sur Gitlab à votre prochain push qui s’occupera de lancer tous les tests nécessaires avant de valider votre push.

Le déploiement continu

Une fois que vos stages sont passés sans encombre, vous voyez votre Pipeline changer de statut pour “passed”. 

Le comportement par défaut est alors un push habituel vers votre branche principale master et mettre à jour votre dépôt. 
C’est ce qu’on nomme le déploiement continu parce qu’il ne nécessite pas d’autre action de votre part. 
La livraison continue (dont les initiales sont aussi CD pour Continuous Delivery) part du même principe sauf que vous devez manuellement valider la mise à jour du dépôt par un “merge”.

Vous retrouverez le détail de tout ça sur l'interface de Gitlab (vous pouvez même suivre le déroulé en temps réel !)

Et en cas de succès ou d’échec vous aurez un email pour vous prévenir, c’est pas beau ça ? 😀