Comment maintenez-vous le code de développement et le code de production ?

Question

Quelles sont les meilleures pratiques et les règles d'or à suivre lors de la maintenance du code ? Est-ce une bonne pratique de n'avoir que le code prêt pour la production dans la branche de développement, ou le dernier code non testé doit-il être disponible dans la branche de développement ?

Comment maintenez-vous votre code de développement et votre code de production ?

Edit - Question supplémentaire - Votre équipe de développement suit-elle le protocole "commit-as-soon-as-possible-and-often-even-if-the-code-contains-minor-bugs-or-is-incomplete" ou le protocole "commit-ONLY-perfect-code" lorsqu'elle commet du code dans la branche DEVELOPMENT ?

Answer 1

Mise à jour 2019 :

De nos jours, la question serait vue dans un contexte utilisant Git, et 10 ans d'utilisation de ce système. distribué développement flux de travail (collaborant principalement via GitHub ) présente les meilleures pratiques générales :

• master est la branche prête à être déployée dans la production à tout moment : la prochaine version, avec un ensemble sélectionné de branches de fonctionnalités fusionnées dans master .
• dev (ou branche d'intégration, ou ' next ') est celui où les branches de fonctionnalités sélectionnées pour la prochaine version sont testées ensemble.
• maintenance (ou hot-fix ) est celle qui contient l'évolution de la version actuelle et les corrections de bugs, avec possibilité de fusionner avec dev et ou master

Ce genre de flux de travail (où l'on ne fusionne pas dev a master mais où l'on fusionne uniquement la branche de fonctionnalité vers dev puis, s'il est sélectionné, à master (afin de pouvoir abandonner facilement les branches de fonctionnalités qui ne sont pas prêtes pour la prochaine version) est implémentée dans le repo Git lui-même, avec la balise gitworkflow (un mot, illustré ici ).
Plus d'informations sur rocketraman/gitworkflow . L'histoire de cette pratique par rapport au développement basé sur les troncs est notée dans les commentaires et discussions de cet article par Adam Dymitruk .

(fuente: Gitworkflow : Une introduction axée sur les tâches )

Note : dans ce workflow distribué, vous pouvez commiter quand vous voulez et pousser vers une branche personnelle des WIP (Work In Progress) sans problème : vous pourrez réorganiser (git rebase) vos commits avant de les intégrer à une branche de fonctionnalité.

---

Réponse originale (Oct. 2008, il y a 10+ ans)

Tout dépend de la la nature séquentielle de votre gestion des rejets

D'abord, est-ce que tout ce qui est dans votre coffre vraiment pour la prochaine version ? Vous découvrirez peut-être que certaines des fonctions actuellement développées sont les suivantes :

• trop compliqué et doit encore être affiné
• pas prêt à temps
• intéressant mais pas pour cette prochaine version

Dans ce cas, le tronc doit contenir tous les efforts de développement actuels, mais une branche de version définie tôt avant la prochaine version peut servir de branche de consolidation dans laquelle seul le code approprié (validé pour la prochaine version) est fusionné, puis corrigé pendant la phase d'homologation, et enfin gelé lors de la mise en production.

Lorsqu'il s'agit de code de production, vous devez aussi gérer votre branches du patch tout en gardant à l'esprit que :

• le premier ensemble de correctifs peut en fait commencer avant la première mise en production (ce qui signifie que vous savez que vous allez entrer en production avec certains bogues que vous ne pourrez pas corriger à temps, mais vous pouvez commencer à travailler sur ces bogues dans une branche séparée).
• les autres branches du patch auront le luxe de partir d'un label de production bien défini

En ce qui concerne la branche de développement, vous pouvez avoir un tronc, à moins que vous n'ayez d'autres efforts de développement à fournir. en parallèle comme :

• refactoring massif
• l'essai d'une nouvelle bibliothèque technique qui pourrait changer la façon dont vous appelez les choses dans d'autres classes
• le début du cycle d'une nouvelle version où d'importants changements architecturaux doivent être intégrés.

Maintenant, si votre cycle de développement et de publication est très séquentiel, vous pouvez simplement faire comme les autres réponses suggèrent : un tronc et plusieurs branches de publication. Cela fonctionne pour les petits projets où tout le développement est sûr d'aller dans la prochaine version, et peut simplement être gelé et servir de point de départ pour la branche de publication, où les correctifs peuvent avoir lieu. C'est le processus nominal, mais dès que vous avez un projet plus complexe... ce n'est plus suffisant.

---

Pour répondre au commentaire de Ville M. :

• gardez à l'esprit que la branche dev ne signifie pas "une branche par développeur" (ce qui déclencherait la "folie de la fusion", dans la mesure où chaque développeur devrait fusionner le travail des autres pour voir/obtenir leur travail), mais une branche dev par effort de développement.
• Lorsque ces efforts doivent être réintégrés dans le tronc (ou toute autre branche "principale" ou de publication que vous définissez), c'est le travail du développeur, no - Je répète, PAS - le directeur du SC (qui ne saurait pas comment résoudre une fusion conflictuelle). Le chef de projet peut superviser la fusion, c'est-à-dire s'assurer qu'elle commence/se termine à temps.
• quel que soit le choix que vous ferez pour effectuer la fusion, le plus important est.. :
  • de disposer de tests unitaires et/ou d'un environnement d'assemblage dans lequel vous pouvez déployer/tester le résultat de la fusion.
  • d'avoir défini une balise avant au début de la fusion afin de pouvoir revenir à l'état précédent si ladite fusion s'avère trop complexe ou plutôt longue à résoudre.

Answer 2

Nous utilisons :

• branche de développement exclusivement

jusqu'à ce que le projet soit presque terminé, ou que nous créions une version intermédiaire (par exemple, une version de démonstration ou de présentation du produit), alors nous nous séparons (régulièrement) de la branche de développement actuelle pour passer à la branche de développement :

• branche de libération

Aucune nouvelle fonctionnalité n'est intégrée à la branche de publication. Seuls les bogues importants sont corrigés dans la branche de publication, et le code pour corriger ces bogues est réintégré dans la branche de développement.

Le processus en deux parties avec une branche de développement et une branche stable (release) nous facilite grandement la vie, et je ne pense pas que nous puissions améliorer quoi que ce soit en introduisant davantage de branches. Chaque branche a également son propre processus de construction, ce qui signifie que toutes les deux minutes, un nouveau processus de construction est lancé et qu'après une vérification du code, nous avons un nouvel exécutable de toutes les versions et branches de construction en une demi-heure environ.

Occasionnellement, nous avons aussi des branches pour un seul développeur travaillant sur une technologie nouvelle et non éprouvée, ou créant une preuve de concept. Mais généralement, cela n'est fait que si les changements affectent de nombreuses parties de la base de code. Cela se produit en moyenne tous les 3 ou 4 mois et une telle branche est généralement réintégrée (ou supprimée) au bout d'un mois ou deux.

En général, je n'aime pas l'idée que chaque développeur travaille dans sa propre branche, car on "saute le pas et on passe directement à l'enfer de l'intégration". Je le déconseille fortement. Si vous avez une base de code commune, vous devriez tous y travailler ensemble. Cela rend les développeurs plus méfiants à propos de leurs checkins, et avec l'expérience, chaque codeur sait quelles modifications sont susceptibles de casser le build et donc les tests sont plus rigoureux dans de tels cas.

Sur la question de l'enregistrement précoce :

Si vous souhaitez uniquement CODE PARFAIT pour être enregistré, alors en fait rien ne devrait être enregistré. Aucun code n'est parfait, et pour que l'AQ puisse le vérifier et le tester, il doit se trouver dans la branche de développement afin qu'un nouvel exécutable puisse être construit.

Pour nous, cela signifie qu'une fois qu'une fonctionnalité est terminée et testée par le développeur, elle est enregistrée. Elle peut même être enregistrée s'il y a des bogues connus (non fatals), mais dans ce cas, les personnes qui seraient affectées par le bogue sont généralement informées. Le code incomplet ou en cours de développement peut également être validé, mais uniquement s'il ne provoque pas d'effets négatifs évidents, comme des plantages ou la rupture de fonctionnalités existantes.

De temps en temps, un contrôle combiné inévitable du code et des données rendra le programme inutilisable jusqu'à ce que le nouveau code ait été construit. Le moins que nous puissions faire est d'ajouter un "WAIT FOR BUILD" dans le commentaire du check-in et/ou d'envoyer un e-mail.

Answer 3

Pour ce que ça vaut, voici comment nous procédons.

La plupart des développements sont effectués dans le tronc, bien que les fonctionnalités expérimentales ou les choses qui pourraient briser le système de manière significative ont tendance à obtenir leur propre branche. Cela fonctionne plutôt bien car cela signifie que chaque développeur dispose toujours de la dernière version de tout dans sa copie de travail.

Cela signifie qu'il est important de maintenir le coffre en état de marche, car il est parfaitement possible de le casser complètement. En pratique, cela n'arrive pas souvent, et c'est rarement un problème significatif.

Pour une version de production, nous branchons le tronc, arrêtons d'ajouter de nouvelles fonctionnalités et travaillons à la correction des bogues et aux tests de la branche (en fusionnant régulièrement avec le tronc) jusqu'à ce qu'elle soit prête à être publiée. À ce moment-là, nous faisons une fusion finale dans le tronc pour nous assurer que tout y est, puis nous publions.

La maintenance peut alors être effectuée sur la branche release si nécessaire, et ces corrections peuvent être facilement réintégrées dans le tronc.

Je ne prétends pas qu'il s'agisse d'un système parfait (et il a encore quelques lacunes - je ne pense pas que notre gestion des versions soit encore un processus suffisamment rigoureux), mais il fonctionne suffisamment bien.

Answer 4

Pourquoi personne n'en parle encore ? Un modèle de branchement Git réussi .

C'est pour moi le modèle de branchement ultime !

Si votre projet est petit, n'utilisez pas tout le temps toutes les différentes branches (vous pourriez peut-être sauter les branches de fonctionnalités pour les petites fonctionnalités). Mais sinon, c'est la façon de faire !

Answer 5

Le dev va dans le tronc (style svn) et les versions (code de production) ont leurs propres branches.

Il s'agit du "modèle de la branche par objectif" (figure 3 en L'importance des modèles d'embranchement /!\ pdf)