Qu'est-ce qu'un système de contrôle de version centralisé ?

Dans un système de contrôle de version (CVCS) centralisé, également connu sous le nom de contrôle de source centralisé ou de système de gestion de versions, un serveur agit comme le dépôt centralisé principal qui stocke chaque version du code. À l'aide d'un contrôle de source centralisé, chaque utilisateur valide directement dans la branche principale. Ce type de contrôle de version fonctionne donc souvent bien pour les petites équipes, car les membres ont la possibilité de communiquer rapidement afin d'éviter que deux développeurs ne travaillent sur le même morceau de code simultanément. Une communication et une collaboration solides sont importantes pour assurer la réussite d'un workflow centralisé.

Les systèmes de contrôle de version centralisés, tels que CVS, Perforce et SVN, exigent que les utilisateurs extraient la dernière version du serveur pour télécharger une copie locale sur leur machine. Les contributeurs poussent ensuite des validations sur le serveur et résolvent tout conflit de fusion sur le dépôt principal.

En tant que modèle client-serveur, un workflow centralisé permet le verrouillage de fichiers afin qu'aucun élément du code actuellement exécuté via la commande git checkout ne soit accessible à d'autres, ce qui assure qu'un seul développeur à la fois contribue au code. Les membres de l'équipe utilisent des branches pour contribuer au dépôt central, et le serveur déverrouille les fichiers après les fusions.

Les systèmes de contrôle de version centralisés les plus courants sont Concurrent Versions System (CVS), Perforce et Subversion (SVN). Il y a aussi Microsoft Team Foundation Server (TFS), qui est maintenant connu sous le nom d'Azure DevOps Server.

Il est à noter que Git, le système de contrôle de version le plus courant n'est pas un système de contrôle de version (VCS) centralisé, mais plutôt un système de contrôle de version (VCS) distribué.

Fonctionne bien avec les fichiers binaires

Les fichiers binaires, tels que les ressources graphiques et les fichiers texte, nécessitent une grande quantité d'espace, de sorte que les développeurs de logiciels se tournent vers des systèmes de contrôle de version centralisés pour stocker ces données. Avec un serveur centralisé, les équipes peuvent tirer quelques lignes de code sans enregistrer l'historique complet sur leur ordinateur local. Les utilisateurs de systèmes distribués doivent télécharger l'ensemble du projet, ce qui prend du temps et de l'espace, et les empêchent en outre de faire des diffs. Si une équipe travaille régulièrement avec des fichiers binaires, un système centralisé constitue l'approche la plus efficace pour le développement de code.

Offre une visibilité complète

Avec un emplacement centralisé, chaque membre de l'équipe a une visibilité complète du code sur lequel il travaille actuellement et des modifications apportées. Ces informations aident les équipes de développement logiciel à comprendre l'état d'un projet et fournissent une base pour la collaboration, car les développeurs partagent le travail sur le serveur central. Un système de contrôle de version centralisé ne contient que deux dépôts de données que les utilisateurs doivent surveiller : la copie locale et le serveur central.

Diminue la courbe d'apprentissage

Le contrôle de version centralisé est facile à comprendre et à utiliser, de sorte que les développeurs de tout niveau de compétence peuvent apporter des modifications et commencer à contribuer rapidement au code base. La configuration du système et du workflow est également simple et ne nécessite pas un investissement en temps important pour déterminer comment l'équipe de développement logiciel doit utiliser l'outil. Lorsque les développeurs peuvent naviguer dans un workflow rapidement et facilement, ils peuvent se concentrer sur le développement de fonctionnalités au lieu de mémoriser une série d'étapes compliquées pour fusionner les modifications versionnées. La diminution de la courbe d'apprentissage aide également les nouveaux développeurs à avoir un impact dès que possible.

Un point de défaillance unique risque de compromettre les données

Le principal inconvénient est le point de défaillance unique intégré au serveur centralisé. Si le serveur distant tombe en panne, personne ne peut travailler sur le code ou pousser les modifications. L'absence d'accès hors ligne signifie que toute perturbation peut avoir un impact significatif sur le développement de code et même entraîner une perte de code. L'ensemble du projet et de l'équipe sont à l'arrêt lors d'une panne. En cas de corruption du disque dur, les équipes de développement logiciel doivent s'appuyer sur des sauvegardes pour récupérer l'historique d'exécution d'un projet. Si les sauvegardes n'ont pas été conservées correctement, l'équipe perd tout. Lorsque toutes les versions sont stockées sur un serveur central, les équipes risquent de perdre leur code source à tout moment. Seuls les instantanés sur les ordinateurs locaux sont récupérables, mais il s'agit d'une petite quantité de code par rapport à l'historique complet d'un projet.

Contrairement à un VCS centralisé, un système de contrôle de version distribué permet à chaque utilisateur de disposer d'une copie locale de l'historique d'exécution sur son ordinateur. Ainsi, en cas de panne, chaque copie locale devient une copie de sauvegarde et les membres de l'équipe peuvent continuer à développer hors ligne.

La lenteur retarde le développement

Les utilisateurs du système de contrôle de version centralisé ont souvent du mal à créer des branches rapidement, car les utilisateurs doivent communiquer avec le serveur distant pour chaque commande, ce qui ralentit le développement du code.

Le branchement devient alors une tâche chronophage qui peut engendrer des conflits de fusion, car les développeurs ne peuvent pas transférer leurs modifications vers le dépôt central assez rapidement pour que leurs collègues puissent les consulter. Si les membres de l'équipe font face à des connexions réseau lentes, le processus de développement du code devient encore plus fastidieux lorsqu'ils tentent de se connecter au serveur distant.

La vitesse à laquelle les équipes de développement de logiciels opèrent a un impact direct sur la rapidité avec laquelle elles peuvent proposer des fonctionnalités et générer de la valeur commerciale. Si le processus de développement est lent, l'itération et l'innovation stagnent et les développeurs peuvent être frustrés par le temps nécessaire pour voir apparaitre leurs modifications dans l'application. Il est possible que certaines versions de release ne soient pas publiées si les réseaux ou le serveur distant sont défaillants et si les membres de l'équipe ne peuvent pas rattraper le temps perdu et pousser rapidement les modifications.

Nombre limité de moments stables pour pousser les changements

Un workflow centralisé est facile à utiliser pour les petites équipes, mais peut présenter des limites lorsque des équipes plus importantes tentent de collaborer. Lorsque plusieurs développeurs souhaitent travailler sur le même morceau de code, il devient difficile de trouver un moment stable pour pousser les modifications. Les modifications instables ne peuvent pas être poussées vers le dépôt central principal. Les développeurs doivent donc les conserver en local jusqu'à ce qu'elles soient prêtes à passer au stade de release.

Lorsque les utilisateurs retardent la poussée des modifications, cela peut également retarder les projets de développement logiciel et entraîner des conflits de fusion, car le reste de l'équipe n'a aucune visibilité sur les modifications qui sont uniquement présentes sur l'ordinateur d'un utilisateur. Une fois que les modifications sont enfin poussées vers le dépôt central (c'est-à-dire lorsque les problèmes de stabilité et de vitesse ont été traités), les utilisateurs doivent résoudre rapidement les conflits lors de la fusion pour s'assurer que le reste de l'équipe peut contribuer au code. Le manque de stabilité est le facteur qui mène de nombreuses équipes à migrer vers un système de contrôle de version différent, comme Git.

Dans le domaine dynamique du développement logiciel, un système de contrôle de version centralisé (CVCS) est la pierre angulaire des équipes visant une collaboration efficace et des processus rationalisés. Ce système exploite la puissance d'un serveur central pour tenir à jour un historique complet des versions. En permettant à chaque développeur de contribuer directement à la branche principale, le CVCS simplifie le processus de développement.

L'essence d'un CVCS réside dans sa capacité à offrir une plateforme unifiée pour le contrôle de version, ce qui garantit que chaque membre de l'équipe travaille avec le code le plus récent afin d'améliorer la productivité et de favoriser une culture de transparence.