2013-09-06 3 views
2

Puisque nous développons sur un système déployé, nous essayons de faire un meilleur usage de l'embranchement - Jusqu'à récemment, à peu près tout était juste vérifié dans le réseau, déployé pour tester/mise en scène et ensuite la production. Cela signifie que nous devons être très prudents pendant la période de "Test", et nous recevons parfois des modifications non désirées envoyées au serveur avec peu de tests. Ma pensée est que la meilleure façon serait que les correctifs "mineurs" soient directement sur le tronc, que les fonctionnalités principales deviennent des branches qui sont réintroduites dans le tronc une fois complétées et un "Production" branch qui correspond toujours à l'état du serveur que nous pouvons fusionner avant le déploiement. Le principal avantage offert ici est que vous pouvez choisir les changements à apporter à la production - si vous le souhaitez, vous pouvez saisir un seul chèque ou succursale et l'envoyer en production sans impliquer toutes les autres succursales. D'autre part, il semble préférable d'avoir des branches souvent intégrées au tronc - tirer les changements de sorte qu'ils ne s'accumulent pas et faire une mauvaise fusion. Par conséquent, ces deux modèles peuvent conduire au cas où vous souhaitez fusionner une branche avec Production afin d'obtenir une fonction importante, mais cette branche a déjà "intégré" les modifications du tronc que vous ne souhaitez pas expédier.SVN Branching/Fusion avec fonctionnalité et branche de production

Est-ce que SVN peut gérer cela? Y a-t-il vraiment de bonnes pratiques qui fonctionnent pour les groupes qui développent du code qui est déployé toutes les deux semaines?

+0

Voulez-vous fusionner la fonctionnalité à la production sans la fusionner au tronc? – maxim1000

+0

Vous aurez plus de chance avec Subversion 1.8. Il apporte des améliorations significatives au moteur de fusion, en particulier pour les cas d'utilisation plus avancés tels que les fusions de frères et soeurs. –

+1

Personnellement, je traiterais le tronc comme un roi: il n'y a pas de développement là-bas, seulement des fusions à partir de branches créées sur le tronc. Vous effectuez le contrôle qualité habituel sur une branche de fonctionnalité et, une fois la connexion terminée, fusionnez-la de nouveau dans le tronçon. Ensuite, étiquetez le coffre et mettez-le en production. Nouvelle fonctionnalité branchez le tronc et le cycle recommence. S'il y a un bogue qui doit être corrigé immédiatement, créez une branche de correction de bogue à partir du tronc à la révision balisée, corrigez le bogue, faites l'AQ, puis fusionnez-le de nouveau, étiquetez et relâchez en production. Il est très facile de suivre ce flux de travail une fois que vous avez effectué quelques versions. Juste mes deux cents. –

Répondre

2

Je pense que tout ce que vous décrivez est possible avec (une version actuelle comme 1.7 ou 1.8 de) Subversion. Voici les étapes à suivre:

  1. Décrivez vos stratégies de branchement (et de fusion). Vous ne pouvez pas facilement tout mélanger, et il est difficile pour les développeurs de savoir quelle stratégie est utilisée, alors la documentation et la communication sont essentielles. Voir les ressources suivantes:
  2. Vous utiliserez les éléments suivants:
    • branche de sortie pour la version de production, les correctifs sont développés directement là-bas. Pour chaque patch, vous devez décider si ce patch doit être disponible (sous la même forme) dans la prochaine version.
    • Utilisez le tronc pour le développement principal. Tout ce que vous êtes sûr que ce sera dans la prochaine version devrait être développé sur le tronc. Ne pas fusionner du tronc à la branche (libérer). Plus jamais!!
    • N'utilisez les branches de fonctionnalité que si vous n'êtes pas sûr qu'une fonctionnalité sera disponible dans la prochaine version. Les branches d'entités sont (dans Subversion) beaucoup plus difficiles que par ex. dans Git, donc il devrait y avoir une raison de les utiliser. Fusionnez régulièrement tous les changements du tronc vers la branche d'entités et réintégrez-les uniquement à la fin, lorsque la fonctionnalité est intégrée dans le tronc (pour passer à la version suivante).
  3. Trouver le point juste à temps pour faire le branchement et la fusion:
    • Branching: Quand une branche stable nécessaire (pour l'intégration à la prochaine version), et quand peut commencer le développement de ce qui suit libérer (puis sur le coffre à nouveau)?Fusion: À quel moment faut-il fusionner les modifications: Immédiat, lorsque le changement est récent; régulièrement de temps en temps; (espérons pas) seulement une fois à la fin.

Vos branches seront développées au fil du temps comme celui-ci:

  1. Vous commencez avec le tronc (et seul le tronc) pour la version 1.0, la première version.
  2. Vous branchez la jonction lorsque vous souhaitez effectuer des tests d'intégration pour la version 1.0 et démarrer le développement de la version 1.1 (sur la jonction).
  3. Vous livrez la version 1.0 et fournissez ensuite des correctifs directement à partir de la branche.
  4. Vous branchez la jonction lorsque vous souhaitez effectuer des tests d'intégration pour la version 1.1 et démarrer le développement de la version 1.2 (ou 2.0) sur la jonction.
  5. ... et ainsi de suite ...

Branching and Merging du Livre rouge SVN explique tout ce dont vous avez besoin sur le plan technique, mais n'est pas si clair comment le faire dans différents contextes d'affaires (mon opinion personnelle). Je n'ai pas trouvé une ressource qui explique toutes les options et les pilotes derrière eux avec suffisamment de détails ...

+0

Existe-t-il un moyen de gérer le cas où une entité est vérifiée dans le tronc, d'autres branches d'entités fusionnent ces modifications puis sont réintégrées dans le tronc, mais vous souhaitez les expédier sans la première fonctionnalité? –

+0

Je jouais juste avec SVN et je pense que j'ai répondu à ma propre question - "Revenir aux changements apportés par cette révision" semble faire le travail très bien. –

Questions connexes