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.

En résumé

Cette leçon explique le cycle de vie traditionnel des applications logicielles avant l'adoption des méthodologies modernes. Plusieurs équipes (développement front, développement back, opération, test) travaillent en parallèle sur des branches de code séparées en utilisant des plateformes comme GitLab, GitHub ou Bitbucket pour coordonner leur travail. Le code traverse successivement les phases de développement, intégration, test et correction, les bugs étant renvoyés aux développeurs avant le déploiement en production. Ce processus itératif, qui peut durer des semaines ou des mois, représente l'approche conventionnelle du développement logiciel.

Points clés

Travail en parallèle avec plusieurs équipes et branches de code séparées pour éviter les conflits
Cycle de vie en phases successives: développement → intégration → test → correction → déploiement
Utilisation de plateformes comme GitLab, GitHub et Bitbucket pour gérer les branches et coordonner les équipes
Itérations répétées du cycle complet jusqu'à la correction totale des bugs avant déploiement en production
Processus long et fatigant pour les équipes, pouvant prendre des semaines ou des mois
Chaque équipe (frontend, backend, opération, qualité) a un rôle précis dans le cycle de vie

Questions fréquentes

Pourquoi les développeurs utilisent-ils des branches séparées plutôt que de travailler directement sur le code partagé?

Les branches séparées isolent le travail de chaque développeur ou équipe, permettant le travail en parallèle sans conflits. Plusieurs développeurs peuvent ainsi travailler simultanément sur différentes parties de l'application (paiement, menu, base de données) de manière indépendante avant la fusion du code.

Quel est le processus quand l'équipe de test découvre des bugs?

Les bugs trouvés lors des tests sont retournés à l'équipe de développement qui doit les corriger, ce qui entraîne une nouvelle itération du cycle complet de développement, intégration et test jusqu'à ce que tous les problèmes soient résolus.

Quels outils sont utilisés pour gérer les branches de code et coordonner le travail entre équipes?

Des plateformes comme GitLab, GitHub et Bitbucket offrent les fonctionnalités nécessaires pour gérer les branches, permettre le travail en parallèle des développeurs et coordonner l'intégration du code source entre les différentes équipes.