Comment gérez-vous le code de développement et le code de production? [fermé]

Quelles sont les meilleures pratiques et règles générales à suivre tout en conservant le code? Est-il recommandé de n'avoir que le code prêt pour la production dans la branche de développement, ou le dernier code non testé devrait-il être disponible dans la branche de développement?

Comment gérez-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-dès-que-possible-et-souvent-même-si-le-code-contient-des-bogues-mineurs-ou-est-incomplet" ou "commit- Protocole ONLY-perfect-code "lors de la validation du code dans la branche DEVELOPMENT?

Mise à jour 2019:

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

• masterLa branche est-elle prête à être déployée en production à tout moment: la prochaine version, avec un ensemble sélectionné de branches de fonctionnalités fusionnées master.
• dev(ou branche d'intégration, ou ' next') est celle où la branche de fonctionnalité sélectionnée pour la prochaine version est testée ensemble
• maintenance(ou hot-fix) branche est celle pour l'évolution de la version actuelle / les corrections de bogues, avec des fusions possibles vers devet oumaster

Ce type de flux de travail (où vous ne fusionnez pas devavec master, mais où vous ne fusionnez que la branche de fonctionnalité vers dev, puis s'il est sélectionné, vers master, afin de pouvoir supprimer facilement les branches de fonctionnalité non prêtes pour la prochaine version) est implémenté dans Git repo lui-même, avec le gitworkflow (un mot, illustré ici ).
En savoir plus sur rocketraman/gitworkflow. L'historique de cette opération par rapport au développement basé sur le tronc est noté dans les commentaires et les discussions de cet article par Adam Dymitruk .

^{(source: Gitworkflow: un guide axé sur les tâches )}

Remarque: dans ce flux de travail distribué, vous pouvez valider quand vous le souhaitez et pousser dans 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és.

Réponse originale (oct.2008, il y a plus de 10 ans)

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

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

• trop compliqué et a encore besoin d'ê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 en cours, mais une branche de publication 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é lors de la phase d'homologation, et enfin congelé au fur et à mesure qu'il entre en production.

En ce qui concerne le code de production, vous devez également gérer vos branches de correctifs , 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 pouvez pas corriger à temps, mais vous pouvez lancer le travail pour ces bogues dans une branche séparée)
• les autres branches de 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 que vous devez faire en parallèle comme:

• refactoring massif
• test d'une nouvelle bibliothèque technique qui pourrait changer la façon dont vous appelez les choses dans d'autres classes
• début d'un nouveau cycle de publication où d'importants changements architecturaux doivent être incorporés.

Maintenant, si votre cycle de développement-version est très séquentiel, vous pouvez simplement suivre les autres réponses: un tronc et plusieurs branches de version. 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 de développement ne signifie pas `` une branche par développeur '' (ce qui déclencherait la `` folie de fusion '', en ce que chaque développeur devrait fusionner le travail des autres pour voir / obtenir leur travail), mais une branche de développement par développement effort.
• Lorsque ces efforts doivent être fusionnés dans le tronc (ou toute autre branche «principale» ou de version que vous définissez), c'est le travail du développeur, pas - je le répète, PAS - le gestionnaire SC (qui ne saurait pas comment résoudre toute fusion conflictuelle). Le chef de projet peut superviser la fusion, c'est-à-dire s'assurer qu'elle commence / se termine à temps.
• qui que vous choisissiez pour effectuer la fusion, le plus important est:
  • pour avoir des tests unitaires et / ou un environnement d'assemblage dans lequel vous pouvez déployer / tester le résultat de la fusion.
  • avoir défini une balise avant le début de la fusion afin de pouvoir revenir à l'état précédent si ladite fusion s'avère trop complexe ou assez longue à résoudre.

Nous utilisons:

• branche de développement exclusivement

jusqu'à ce que le projet soit presque terminé, ou que nous créions une version jalon (par exemple, une démonstration de produit, une version de présentation), puis nous divisons (régulièrement) notre branche de développement actuelle dans:

• branche de libération

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

Le processus en deux parties avec une branche de développement et une branche stable (release) nous facilite beaucoup la vie, et je ne crois pas que nous pourrions en améliorer une partie en introduisant plus 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 généré et donc, après un enregistrement de code, nous avons un nouvel exécutable de toutes les versions de construction et des branches dans environ une demi-heure.

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

En général, je n'aime pas l'idée que chaque développeur travaille dans sa propre branche, parce que vous «passez 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 vérifications, et avec l'expérience, chaque codeur sait quels changements peuvent potentiellement interrompre la construction et les tests sont donc plus rigoureux dans de tels cas.

À la question de l'enregistrement anticipé:

Si vous n'avez besoin que de PERFECT CODE pour être archivé, alors en fait rien ne doit être archivé. Aucun code n'est parfait, et pour que le QA le vérifie et le teste, il doit être 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 complète et testée par le développeur, elle est archivée. Elle peut même être archivée s'il existe des bogues connus (non fatals), mais dans ce cas, les personnes qui seraient affectées par le bogue sont généralement informé. Le code incomplet et en cours de travail peut également être archivé, 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 inévitable enregistrement combiné du code et des données rendra le programme inutilisable jusqu'à ce que le nouveau code soit construit. Le moins que nous fassions est d'ajouter un "WAIT FOR BUILD" dans le commentaire d'enregistrement et / ou d'envoyer un e-mail.

Pour ce que ça vaut, c'est ainsi que nous le faisons.

La plupart des développements sont effectués dans le tronc, bien que les fonctionnalités expérimentales ou les éléments susceptibles de casser le système aient tendance à avoir leur propre branche. Cela fonctionne plutôt bien car cela signifie que chaque développeur a toujours la dernière version de tout dans sa copie de travail.

Cela signifie qu'il est important de garder le coffre en état de fonctionnement vague, car il est parfaitement possible de le casser complètement. En pratique, cela n'arrive pas souvent et représente rarement un problème important.

Pour une version de production, nous branchons le tronc, arrêtons d'ajouter de nouvelles fonctionnalités, et travaillons sur la correction de bogues et testons la branche (fusionnant régulièrement dans le tronc) jusqu'à ce qu'elle soit prête à être publiée. À ce stade, nous effectuons une fusion finale dans le coffre pour nous assurer que tout y est, puis relâchons.

La maintenance peut ensuite être effectuée sur la branche de publication si nécessaire, et ces correctifs peuvent être facilement fusionnés dans le coffre.

Je ne prétends pas que ce soit un système parfait (et il a encore quelques trous - je ne pense pas que notre gestion des versions soit encore un processus assez serré), mais cela fonctionne assez bien.

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 ignorer les branches de fonctionnalités pour les petites fonctionnalités). Mais sinon, c'est la manière de le faire!

Code de développement sur les branches, code live taggé sur Trunk.

Il n'est pas nécessaire d'avoir une règle de "validation uniquement du code parfait" - tout ce que le développeur manque doit être récupéré à quatre endroits: la revue du code, les tests de branche, les tests de régression, les tests finaux de contrôle qualité.

Voici une explication plus détaillée étape par étape:

1. Faites tout le développement sur une branche, en vous engageant régulièrement au fur et à mesure.
2. Examen indépendant du code des changements une fois que tout le développement est terminé.
3. Passez ensuite la branche à Testing.
4. Une fois le test de la branche terminé, fusionnez le code dans la branche Release Candidate.
5. La branche Release Candidate est testée par régression après chaque fusion individuelle.
6. Tests QA et UA finaux effectués sur RC après la fusion de toutes les branches de développement.
7. Une fois QA et UAT passés, fusionnez la branche release dans la branche MAIN / TRUNK.
8. Enfin, marquez le tronc à ce stade et déployez cette balise sur Live.

dev va dans le coffre (style svn) et les versions (code de production) obtiennent leurs propres branches

C'est le "modèle de branchement par objectif" (figure 3 dans L'importance des modèles de branchement /! \ Pdf)

Nous résolvons ce problème en séparant complètement le code de production (le tronc principal) du code de développement (où chaque développeur a sa propre branche).

Aucun code n'est autorisé dans le code de production avant qu'il n'ait été soigneusement vérifié (par le contrôle qualité et les réviseurs de code).

De cette façon, il n'y a pas de confusion sur le code qui fonctionne, c'est toujours la branche principale.

Oh oui - une autre chose - nous conservons le code de non-production (c'est-à-dire ce qui ne sera JAMAIS publié - par exemple des scripts d'outils, des utilitaires de test) dans cvs HEAD. Habituellement, il doit être clairement marqué pour que personne ne le libère «accidentellement».

Nous développons sur tronc qui est ensuite ramifié toutes les deux semaines et mis en production. Seuls les bogues critiques sont corrigés dans la branche, le reste peut attendre encore deux semaines.

Pour le tronc, la seule règle est qu'un commit ne doit rien casser. Pour gérer le code d'effacement et le code non testé, nous ajoutons simplement les instructions appropriées pour faciliter l'activation et la désactivation.

Fondamentalement, il serait possible de brancher le tronc à tout moment et de le mettre en production.

J'utilise git et j'ai 2 branches: master et maint

• master - code de développement
• maint - code de production

quand je publie du code en production, je le tague et je fusionne le master avec la branche maint . Je déploie toujours depuis la branche maint . Patches de la branche de développement Je les sélectionne pour maintenir la branche et déployer des patches.

Nous avons une branche "release" qui contient ce qui est actuellement en production ou qui sera déployé prochainement (déjà passé la plupart des QA)

Chaque projet, ou dans certains cas une autre unité, a sa propre branche qui est branchée à partir de la version.

Les modifications sont validées, par les développeurs du projet, dans la propre branche de leur projet. Périodiquement, la version est fusionnée dans une branche de développement.

Une fois que les packages de travail sur la branche sont tous contrôlés par QA (test unitaire, test système, revue de code, revue QA, etc.), la branche est fusionnée dans la branche de publication. Les nouvelles versions sont construites à partir de la branche de publication et la validation finale se produit sur cette version.

Le processus est fondamentalement OK jusqu'à ce qu'un problème soit découvert après qu'une fusion ait été effectuée. Si un WP est "bloqué" après avoir été fusionné, il retient tout ce qui suit jusqu'à ce qu'il soit réparé (nous ne pouvons pas faire une autre version tant que la version bloquée n'est pas publiée).

C'est aussi un peu flexible - un changement très insignifiant pourrait se produire directement sur la branche de publication si elle était publiée sur une échelle de temps très courte (comme 1 à 2 jours environ).

Si une modification était directement mise en production pour une raison quelconque (un problème de production critique affectant le client qui nécessitait une modification immédiate du code pour être corrigée), ces modifications seraient replacées dans BRANCH_RELEASE. Cela n'arrive presque jamais.

Cela depend du projet. Notre code Web est archivé de manière assez cohérente, tandis que notre code d'application n'est archivé que s'il se compile. J'ai remarqué que c'est assez similaire à la façon dont nous publions les choses. Le contenu Web augmente chaque fois que cela est possible pendant que les applications atteignent une date limite. Cependant, je n'ai constaté aucune perte de qualité dans les deux méthodes.