Choix du flux de travail de contrôle de version

Question

J'ai été chargé de rechercher comment améliorer la façon dont mon entreprise gère le contrôle de version.

Contexte

Actuellement nous utilisons Borland StarTeam, qui a quelques problèmes. En plus d'être souvent difficile à utiliser, le nombre d'outils (support IDE, revue de code, ...) qui le supportent est très faible.

Notre société a quelque chose comme 40 développeurs, mais nous travaillons avec de nombreux projets différents. Un projet donné a généralement quelque chose comme 3-6 développeurs de logiciels travaillant ensemble. Nos projets vont de la plupart des systèmes embarqués et du développement FPGA aux applications de bureau.

Le flux de travail actuel est fortement centralisé avec une "vue" (proche d'une branche dans le langage StarTeam) sur laquelle travaille tout le monde dans le projet. L'un des projets utilise plusieurs vues de la manière suivante: Cette vue a alors deux sous-vues pour deux produits spécifiques qui partagent le plus de code (via la vue de la plate-forme) mais qui sont assez dissemblables pour être séparés. Tout le développement est fait dans les deux vues de produit et parfois le code d'une vue de produit est promu à la vue de plate-forme (qui est alors automatiquement disponible pour l'autre produit).

Un autre projet semble utiliser une vue principale et une vue de fonctionnalité lorsqu'il y avait un ajout de fonctionnalité majeur.

Nous devons généralement prendre en charge les logiciels pendant une longue période et fournir des mises à jour logicielles.

Certains de nos produits ont un grand nombre de versions différentes. Les différentes versions partageront la plupart du code mais certaines parties sont et doivent être distinctement différentes.

Les développeurs utilisent Windows et Linux sur leurs postes de travail de développement.

Idée

Mon idée est de passer à utiliser un DVCS moderne. Le flux de travail que je considère est où chaque projet a un certain nombre de branches publiques que chaque développeur peut cloner et travailler. Chaque projet pourrait alors déterminer si tout le monde peut s'engager librement, ou si nous devrions avoir un système de gardiennage où le code doit passer un système de construction humain ou automatisé avant d'être engagé dans la branche publique.

Mon idée sur la configuration de branchement est d'utiliser des branches de libération et fonctions, comme dans le scénario suivant:

Supposons que nous commençons par le développement et enfin expédier la version 1.0 de notre produit. Nous constatons alors que nous voulons plus de fonctionnalités, donc nous visons une version 2.0 et commençons une nouvelle branche pour cela. En travaillant sur la branche release 2.0, nous pouvons toujours faire de la maintenance sur la branche 1.0 menant à la version 1.1, et ainsi de suite. En travaillant sur la branche 2.0, nous découvrons un problème de sécurité qui est résolu. Comme il est également disponible dans la branche 1.0, ce code est également rétroporté dans la branche 1.0.

Parfois, dans la branche 2.0, on découvre que certaines parties du système doivent être complètement refaites pour pouvoir créer la fonction X. Une nouvelle branche publique 2.0-feature-X est créée et travaillée. Une fois terminé, le travail dans cette branche est fusionné dans la branche 2.0 principale.

questions réelles

Espérons que vous êtes en train de lire encore à ce stade :)

1. est le flux de travail ci-dessus (libération et fonction de branchement) une option viable? Y a-t-il des chutes de fosse à surveiller?

2. Dans le scénario où un produit a une branche de plate-forme et plusieurs branches de produits, quelle est la meilleure façon de gérer cela? Est-ce que la création d'une branche principale et des branches de produits fonctionnerait? Y a-t-il un problème lorsque deux branches de produits divergent? Combien peuvent-ils diverger?

3. Ai-je manqué quelque chose? Je vois surtout VCS du point de vue du développeur, donc il me manque des choses importantes du point de vue d'un gestionnaire de configuration ou de version.

Answer 1

Pour votre deuxième question, je pense que vous pouvez le code lié à la plate-forme et « la plupart du code » partagé par les différents produits, et seule branche le code source qui rend les produits « dissemblables ». Avec Partager, si un élément est modifié dans un projet, les modifications seront répercutées dans d'autres projets simultanément. Avec Branch, le fichier et ses contreparties sont indépendants. Par conséquent, les deux branches de produits peuvent être divergées autant que vous le souhaitez.