Gitlab 1-4 Approche conventionnelle sans la méthode suivante

Avant l'arrivée de la méthodologie CI/CD, le développement logiciel suivait une approche dite « conventionnelle » qui imposait un cycle long et séquentiel. Une fois les phases de design et de définition terminées, la construction du code commençait : pour un projet d'envergure, le développement était divisé entre plusieurs équipes spécialisées, chacune avec un rôle précis (front-end, back-end, base de données, etc.).

Chaque équipe travaillait sur sa propre branche de code, généralement hébergée sur une plateforme Git comme GitHub, GitLab ou Bitbucket. Plusieurs développeurs pouvaient ainsi travailler en parallèle : un sur la partie paiement, deux autres sur le menu, d'autres encore sur la base de données. Les tests étaient également réalisés en parallèle, chacun dans son périmètre. Dans le pire des cas, certains gardaient le code uniquement en local — pratique heureusement rare.

Le processus de mise en commun

Quand certaines phases de code étaient terminées, il fallait fusionner les branches sur une branche master unique. Le code passait alors à une équipe de QA puis à l'équipe d'opérations, qui devait être informée du déploiement à venir : prérequis d'installation, documentation, configuration… Toutes ces instructions étaient nécessaires pour comprendre comment lancer l'application.

• Déploiement initial dans un environnement de test
• Tests de qualité et d'assurance par l'équipe QA
• Retour aux développeurs en cas de bug ou de problème
• Répétition des phases jusqu'à validation complète
• Déploiement en production (Play Store, App Store, etc.)

Chaque mise à jour devait repasser par l'ensemble de ces phases : on appelle cela une itération. Une itération pouvait durer plusieurs semaines, voire plusieurs mois. C'est cette lenteur, ce coût humain élevé et cette source constante de frustration pour les équipes qui ont poussé l'industrie à moderniser ses méthodes — ce que nous verrons dans la prochaine vidéo avec l'arrivée du CI/CD.