Avant tout, il faut savoir que développer du code c’est comme une dictée de 10 000 mots où l’on vous mettrait 0 à la première faute.

Ça fait peur n’est-ce pas ?

Maintenant dites-vous que plusieurs personnes ont à mettre en commun leurs dictées de 10 000 mots avant qu'elles soient corrigées.

Eh bien, nous vous confirmons que ce n’est pas facile.

Si aucun test de qualité n’est réalisé après la mise en commun des branches de code, alors ce sera votre client qui verra le projet se casser.

Cela peut représenter une véritable bombe à retardement pour vos projets.

TIC…TAC…

Même si chaque morceau du code fonctionne indépendamment sur sa branche, rien ne garantit son bon fonctionnement après avoir été partagé avec ceux des autres développeurs.

Accepteriez-vous de prendre ce risque ?

Voilà l’un des grands problèmes auxquels font face les développeurs : « L’integration Hell ».

Lors de la mise en production, c'est la fusion de ces différents morceaux de code qui peut poser problème, et c’est souvent toute l'équipe technique qui est mobilisée pour retrouver l’aiguille dans la botte de foin.

Pour donner suite à cette petite introduction, vous vous posez sans doute la question :

« Mais comment assurer la stabilité d’un projet de bout en bout ? »

Eh bien c’est là que la CI/CD prend tout son sens !

Sachez que la CI/CD permet de réduire d’au moins 10% les heures consacrées à la maintenance des chaînes d’outils, ce qui n’est pas négligeable !

Source : https://docs.gitlab.com/ee/ci/introduction/

En somme, la CI consiste à automatiser le processus d’intégration des modifications de code dans un projet commun, c’est-à-dire automatiser la vérification de la compatibilité entre les différentes branches du code.

Comment cela s’automatise ?

Comme pour un jeu, il faut « définir les règles ».

La ligne directrice de la CI/CD est dictée par un pipeline, qui est un ensemble d'étapes (build, test, deploy, ...) décrivant les différentes tâches à accomplir pour assurer la qualité du code et autoriser sa fusion avec le tronc (c'est à dire la version partagée) qui peut alors être automatiquement mise en œuvre et testable manuellement dans un environnement de staging : cette mise en œuvre automatisée est appelée "déploiement continu", le fameux "CD" de CI/CD.

Il est plus pratique d’écrire son texte, puis d’activer un correcteur pour relever vos erreurs et tout corriger à la fin; ou d’activer un correcteur automatique qui vous permettra de corriger votre dictée au fur et à mesure ?

Vous entendrez que nous préférons corriger les erreurs dès qu’elles sont identifiées plutôt que de tout corriger à la fin.

En développement ce n’est pas Word qui nous corrige mais différents outils qui permettent d'écrire et d'exécuter un pipeline CI/CD, tels que GitLab-CI, Jenkins, ou GitHub Actions, offrant chacun leurs propres avantages.

Nous intégrons les lignes de code au fur et à mesure du développement, cela nous évite d’avoir à tout intégrer en même temps et d’identifier les problèmes à la livraison du projet.

On gagne ainsi en temps et en réactivité.

Agile n’est-ce pas ?

Et pourtant sachez que cela ne suffit pas !

TIC...TAC…TIC

À la suite des tests manuels effectués sur l'environnement de staging par l'équipe de QA (quality assurance), si ceux-ci n'ont relevé aucune issue, il est alors temps de déployer cette version en production (environnement principal, public) ; cette opération est généralement manuelle, afin de donner l'opportunité aux responsables d'effectuer un retour à la version antérieure (rollback) en cas de problème.

Si on saute à l’élastique, rien n’empêche de penser à un filet de sécurité.

Test + Garde-fou = Sécurité

Qu’il s’agisse de la rédaction des tests du pipeline, de la version partagée, ou de la version principale; lorsque l’on développe un projet il est indispensable de bien définir les supports d’entrée de jeu !

Sinon, c’est la zizanie :

Prenons deux développeurs travaillant sur le système d'analyse de l'altitude d'un avion.

L'un s'occupe de programmer le calcul de l'altitude et l'autre le paramétrage du pilote automatique.

Les deux effectuent leur travail et tout fonctionne au premier abord.

Tout fonctionne jusqu’à ce qu’on livre le projet et que le client nous fasse remonter un problème lié au calcul de l’altitude.

Avec la CI/CD, on aurait dans un premier temps défini les unités de mesure dans un pipeline et les branches de code n’auraient pu être intégrées entre elles car elles auraient été jugées incompatibles.

En cherchant, ils se seraient rendu compte que l'un a développé son code avec des mètres comme unité de mesure et le second des pieds.

La détection des problèmes se fait au plus tôt avec la CI/CD tandis que sans, les branches auraient été intégrées et le problème constaté plus tard, ce qui aurait entraîné un retard sur le projet et obligé vos développeurs à passer du temps à les chercher.

S'il n’y avait que ce type de complication, ce serait facile; mais vos équipes de développement sont confrontées à différents problèmes à gérer en même temps comme le versioning par exemple.

Ils travaillent sur un code source et conservent les versions précédentes après modification.

Dans un problème de versioning votre développeur ne développe pas sur la même branche que les autres et peut se retrouver à résoudre des issues qui ont déjà été résolues.

En résumé, le processus de développement en utilisant la CI/CD est partagé en 3 différents points de contrôle pour assurer la stabilité du code : des tests automatisés indépendamment d'un déploiement ("from scratch"), des tests automatisés effectués lors d'un déploiement sur le staging ("live"), et les tests manuels effectués par l'équipe de QA sur le staging avant la mise en production.

Dans l’approche CI/CD, on peut surveiller la stabilité du code tout au long du cycle de vie de l’application et on définit clairement les supports de travail pour éviter toute confusion.

C’est important de pouvoir vérifier en permanence la stabilité du code, notamment quand on le modifie, que l’on retire ou que l’on ajoute des fonctionnalités après avoir traité les retours de vos clients.

En effet, au fur et à mesure qu'un projet se développe, il contient de plus en plus de code, ce qui laisse donc de plus grandes opportunités pour que des bugs viennent s'y loger, soit sous la forme d'une modification entraînant des comportements imprévus dans une partie (à première vue) non liée du système, soit sous la forme d'un scénario de test complexe qui n'a pas été prévu par l'ensemble des développeurs.

Bien qu'il soit possible pour les développeurs et l'équipe QA de revérifier l'intégralité de la base de code et des fonctionnalités du projet à chaque modification, et en plus de constituer un énorme gâchis de temps, cela devient extrêmement difficile voire impossible à mesure que le projet grandit : la durée des tests et correctifs requis devient exponentielle par rapport à la taille de la base de code et du nombre de fonctionnalités.

La CI/CD, en plus d'apporter des garanties sur la robustesse du produit (et de la sérénité pour les développeurs...) permet d'éviter cette courbe exponentielle, quelle que soit la taille du projet.

TIC …TAC… TIC..TAC….

Comme vous pouvez le constater il n’y a pas de BOOM avec la CI/CD. 😁

Voilà comment nous traitons méthodiquement le développement de nos applications à la Digital Factory Paris, on réduit le risque de retard dans nos projets au maximum grâce à une méthode agile et adaptée à nos projets.

Abonnez-vous à notre newsletter

L’APPROCHE CI/CD : LA BONNE PRATIQUE QUI VOUS ÉVITERA UN 0 POINTÉ

Contactez-nous