Comment gérez-vous le code de développement et le code de production?
Quelles sont les meilleures pratiques et règles générales à 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 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-aussitôt que possible-et-souvent-même-si-le-code-contient-des-bugs-mineurs-ou-est-incomplet" ou "commit- Un protocole "SEULEMENT parfait" lors de la validation du code dans la branche DEVELOPPEMENT?
Mise à jour 2019:
De nos jours, la question serait vue dans un contexte utilisant Git, et 10 ans d'utilisation de cela distribué développement workflow (collaborant principalement via GitHub ) montre les meilleures pratiques générales:
masterest la branche 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 dansmaster.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 ensemblemaintenance(ouhot-fix) est la branche pour les corrections d'évolution/bogue de la version actuelle, avec des fusions possibles versdevet oumaster
Ce type de workflow (où vous ne fusionnez pas dev avec master, mais où vous fusionnez uniquement la branche de fonctionnalité vers dev, puis si elle est sélectionnée, vers master, afin de pouvoir supprimer facilement les branches de fonctionnalités non prêtes pour la prochaine version) est implémentée dans le référentiel Git lui-même, avec le gitworkflow (un mot, illustré ici ).
Voir plus à rocketraman/gitworkflow .
(source: Gitworkflow: une introduction orientée tâche )
Remarque: dans ce flux de travail distribué, vous pouvez valider quand vous le souhaitez et pousser vers une branche personnelle un WIP (Work In Progress) sans problème: vous pourrez réorganiser (git rebase) vos validations avant de les intégrer à une branche de fonctionnalité.
Réponse originale (oct. 2008, il y a 10+ ans)
Tout dépend de la nature séquentielle de votre gestion des versions
Tout d'abord, tout est dans votre coffre vraiment pour la prochaine version? Vous découvrirez peut-être que certaines des fonctions actuellement développées sont:
- 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 en cours, mais une branche de version définie tôt avant la prochaine version peut servir de branche de consolidation dans lequel seul le code approprié (validé pour la prochaine version) est fusionné, puis fixé lors de la phase d'homologation, et finalement figé lors de sa mise en production.
En ce qui concerne le code de production, vous devez également gérer vos branches de 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 entrerez en production avec certains bogues que vous ne pouvez pas corriger à temps, mais vous pouvez lancer le travail pour ces bogues dans une branche distincte)
- les autres branches de patch auront le luxe de partir d'une étiquette de production bien définie
En ce qui concerne la branche de développement, vous pouvez avoir un tronc, sauf si vous avez d'autres efforts de développement dont vous avez besoin pour 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 aller comme le suggèrent 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 une "folie de fusion", en ce que chaque développeur devrait fusionner le travail des autres pour voir/obtenir son travail), mais une branche de développement par développement effort.
- Lorsque ces efforts doivent être réintégrés dans le tronc (ou dans toute autre branche "principale" ou de publication que vous définissez), c'est le travail du développeur, pas - Je répète, PAS - le = SC Manager (qui ne saurait pas résoudre une fusion conflictuelle). Le chef de projet peut superviser la fusion, ce qui signifie s'assurer qu'elle démarre/se termine à l'heure.
- qui que vous choisissiez pour faire la fusion, le plus important est:
- d'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 plutôt longue à résoudre.
Nous utilisons:
- branche développement exclusivement
jusqu'à ce que le projet soit presque terminé, ou que nous créons une version de jalon (par exemple, démonstration de produit, version de présentation), nous dérivons (régulièrement) de notre branche de développement actuelle vers:
- branche de sortie
Aucune nouvelle fonctionnalité n'entre dans 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 un développement et une branche stable (version) nous facilite beaucoup la vie, et je ne pense pas que nous pourrions améliorer n'importe quelle 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 génération est généré et donc après une vérification du 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 généralement, 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 branche est généralement réintégrée (ou supprimée) dans 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 "sautez le pas et passez directement à l'enfer de l'intégration". Je le déconseille fortement. Si vous avez une base de code commune, vous devez tous y travailler ensemble. Cela rend les développeurs plus méfiants à propos de leurs enregistrements, et avec l'expérience chaque codeur sait quels changements sont susceptibles de casser la construction et donc les tests sont plus rigoureux dans ces cas.
Sur la première question de l'enregistrement:
Si vous n'avez besoin que de PERFECT CODE pour être archivé, alors rien ne devrait ê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 un nouvel exécutable peut être construit.
Pour nous, cela signifie qu'une fois qu'une fonctionnalité est terminée 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 traitement peut également être archivé, mais uniquement s'il ne provoque pas d'effets négatifs évidents, tels que des plantages ou la rupture de fonctionnalités existantes.
De temps en temps, une inévitable combinaison combinée de code et de 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 comme ça qu'on fait.
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 aient tendance à avoir leur propre branche. Cela fonctionne assez 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 maintenir le coffre en état de marche vague, car il est parfaitement possible de le casser complètement. En pratique, cela ne se produit pas souvent et constitue 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 le test de la branche (fusionnant régulièrement dans le tronc) jusqu'à ce qu'elle soit prête pour la sortie. À ce moment-là, nous faisons 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 tronc.
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? n 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 façon de le faire!
Code de développement sur les branches, code Live tagué sur Trunk.
Il n'est pas nécessaire qu'il y ait une règle de "validation uniquement du code parfait" - tout ce qui manque au développeur doit être récupéré à quatre endroits: la révision du code, les tests de branche, les tests de régression, les tests d'AQ finaux.
Voici une explication étape par étape plus détaillée:
- Faites tout le développement sur une branche, en vous engageant régulièrement au fur et à mesure.
- Examen indépendant du code des modifications une fois que tout le développement est terminé.
- Passez ensuite la branche à Testing.
- Une fois le test de la branche terminé, fusionnez le code dans la branche Release Candidate.
- La branche Release Candidate est testée par régression après chaque fusion individuelle.
- Tests QA et UA finaux effectués sur RC après la fusion de toutes les branches de développement.
- Une fois QA et UAT passés, fusionnez la branche de publication dans la branche MAIN/TRUNK.
- Enfin, étiquetez le tronc à ce stade et déployez ce tag sur Live.
dev va dans le tronc (style svn) et les versions (code de production) ont 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 d'avoir é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.
Nous développons sur tronc qui est ensuite ramifié toutes les deux semaines et mis en production. Seuls les bogues critiques sont corrigés en branche, le reste peut attendre encore deux semaines.
Pour trunk, 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 des instructions if appropriées pour faciliter l'activation et la désactivation.
Fondamentalement, il serait possible de ramifier le tronc à tout moment et de le mettre en production.
Oh oui - une autre chose - nous conservons le code de non-production (c'est-à-dire celui qui ne sera JAMAIS publié - par exemple les scripts d'outils, les utilitaires de test) dans cvs HEAD. Habituellement, il doit être clairement marqué afin que personne ne le libère "accidentellement".
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 compile. J'ai remarqué que c'est assez similaire à la façon dont nous publions les choses. Les trucs Web augmentent chaque fois que cela est possible alors que les applications atteignent une date butoir. Je n'ai cependant pas vu de perte de qualité dans l'une ou l'autre méthode.
J'utilise git et j'ai 2 branches: master et maint
- master - code de développement
- maint - code de production
quand je libère du code en production, je le tague et je fusionne master à maint branch. Je déploie toujours depuis la branche maint. Correctifs de la branche de développement Je les sélectionne dans la branche maint et déploie les correctifs.
Nous avons une branche "release" qui contient ce qui est actuellement en production ou sera déployée sous peu (déjà passé la plupart des AQ)
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 de la branche sont tous QA (test unitaire, test système, révision 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 une fusion. Si un WP se "bloque" après avoir été fusionné, il retient tout ce qu'il reste jusqu'à ce qu'il soit corrigé (nous ne pouvons pas faire une autre version jusqu'à ce que celle qui est bloquée soit libérée).
Il est également quelque peu flexible - un changement très trivial pourrait se produire directement sur la branche de publication s'il était publié sur une échelle de temps très courte (comme 1-2 jours environ).
Si une modification était directement appliquée à la production pour une raison quelconque (un problème de production critique affectant le client qui nécessitait une modification immédiate du code à corriger), ces modifications seraient réintégrées dans BRANCH_RELEASE. Cela n'arrive presque jamais.