Pour la version basée sur les branches, il faut parler du diagramme suivant, qui illustre parfaitement le panorama du processus de gestion de configuration. Tout d’abord, ce schéma est écrit à partir du modèle Git, mais en réalité, Git et Subversion ont compris le concept de gestion du contrôle de version, cependant Git fait un bond qualitatif en avant par rapport à Subversion en matière de gestion de branche et de performance distribuée (mais ce n’est pas le sujet de cet article).
Avant d’introduire le principe de ce graphe, parlons de deux stratégies différentes pour le contrôle général des versions : l’une est « backbone pioneer, branche stable », et l’autre est « backbone stable, branche pioneer ». Comme son nom l’indique, il s’agit de la version stable (version de production), sur le tronc ou sur la branche. Dans le cas des équipes projet traditionnelles utilisant VSS, il est difficile de dire à quel mode elle appartient, principalement parce que VSS lui-même ne dispose pas de stratégie de gestion d’agence, donc de nombreuses équipes projet établissent respectivement deux bibliothèques de versions (ou trois), correspondant à l’environnement de production et à l’environnement de développement, bien sûr, cela constitue aussi une sorte de gestion d’agence déguisée. Cependant, si vous passez à Subversion ou Git comme outil de contrôle de version, la plupart des équipes utilisent le mode trunk stable, c’est-à-dire que le trunk (truck ou master) correspond à un environnement de production stable, et étiquete différentes versions pour indiquer la version de production. Personnellement, je pense que le schéma stable de code dorsale devrait être la solution de gestion de version de code la plus courante à ce jour. L’image ci-dessus est le modèle standard de gestion de la « backbone stable ».
maître : La Subversion correspondante est le camion。 Conformément à la version de production, elle est taguée une fois à chaque sortie.
Branche de libération (également appelée branche d’intégration): Tant que la production est mise à jour, elle doit d’abord être fusionnée dans la branche de version (branche d’intégration). C’est quelque peu similaire à ce que l’équipe projet appelle actuellement le concept de « pré-production » et « environnement simulé ».
Branch développement (branche de développement ou branche de développement): L’environnement auquel est confronté l’environnement de développement.
Branche caractéristique (branche caractéristique): Certaines fonctions indépendantes peuvent être séparées d’une branche de développement distincte. Cela vise principalement à gérer le fait que certaines fonctionnalités peuvent prendre relativement longtemps à être mises à jour, afin de ne pas ralentir la version et les branches séparées.
Branche des correctifs (branche correction de bugs): Le bug ici est principalement un bug de production.
Après avoir introduit le tronc et les branches, je dois indiquer la direction de la génération et de la fusion de ces branches.
Master est la version de production, et le trunk n’accepte que deux branches pour la fusion, l’une est la branche de libération (branche d’intégration) et l’autre la branche des correctifs rapides. Aucune autre branche ne peut être fusionnée dans une branche production.
La branche de sortie est initialement créée en même temps que la production, ce qui est exactement la même que la production. Il n’accepte que la branche développeur pour fusionner avec elle. En d’autres termes, il n’accepte pas la fusion directe depuis la branche feature ou la branche corrections de bugs.
La branche développement, la branche développement, comme la branche intégration, est la même que l’environnement de production à un certain moment. Cependant, au fur et à mesure que le développement progresse, de nouvelles fonctionnalités continueront d’être créées sur la branche développement. La théorie du développement n’accepte que la fusion de deux branches, l’une est des correctifs rapides et l’autre la branche de fonctionnalités.
Branche de fonctionnalités, à partir d’un certain point (version) avec la branche dev, la branche feature finira par fusionner avec la branche dev.
Présentons brièvement la méthode de contrôle de version sous forme de scénario
Supposons qu’une version de production soit divisée en branches (dev, correctifs rapides, release), et qu’à ce moment-là, dev commence à développer un total de dix fonctions. Lorsque 8 des 10 fonctionnalités ont été développées, l’équipe de test a commencé à intervenir pour les tests internes, et l’administrateur de configuration a déployé la branche dev dans l’environnement dev pour des tests via des outils d’intégration continue (un sujet distinct ici). Lorsque la vérification de test a révélé que deux des fonctions étaient totalement inacceptables et devaient être refaites, comme l’assurance simple et la déclaration de sinistre, deux branches de fonctionnalités ont été séparées du développement, correspondant à une assurance simple et au remboursement de sinistre, et dans la branche développement, le code correspondant a également dû être annulé (opération manuelle ici). Lorsque l’équipe de test constate qu’il n’y a aucun problème avec le test de la branche de développement, il remplit les conditions de l’UAT, donc l’administrateur de configuration fusionne la branche dev dans la branche de release, puis utilise des outils d’intégration continue pour publier cette branche dans l’environnement de pré-production et la remettre à l’utilisateur pour test. Lorsque la vérification utilisateur détecte un problème, le développeur modifie la branche dev, puis la fusionne dans la branch release (ici, dans l’image originale, elle est directement modifiée dans la release branch, je pense que ce n’est pas bon, je recommande au développeur de ne faire face qu’à la branch dev), lorsque le processus de vérification de la version détecte soudainement qu’il y a un bug sérieux dans l’environnement de compilation qui doit être corrigé immédiatement, alors il est modifié en urgence sur la branche hotfixes, et il est lancé en urgence après avoir vérifié qu’il est correct. En même temps, la branche des correctifs est fusionnée avec dev (ici c’est principalement manuel, car à ce stade la version de production est déjà très différente de celle de dev, et il est souvent impossible de terminer la fusion automatique), puis dev est fusionné dans la version. Après un certain temps, la fonction de retour de réclamation peut ne plus être nécessaire et doit être annulée, donc la branche de la fonction de retour de réclamation sera supprimée. Une autre fonctionnalité est facile à assurer et a été développée puis intégrée à la branche développement pour lancer la prochaine version en ligne.
Le scénario ci-dessus inclut essentiellement le développement de routine, le déballage, les mises à jour d’urgence et d’autres scénarios dans le processus quotidien de développement.
|
Publié sur 08/04/2018 10:25:39
|
|
|
|
