Meilleures pratiques avec le branchement du code source et le cycle de vie des applications

Nous sommes un petit magasin ISV et nous expédions généralement une nouvelle version de nos produits chaque mois. Nous utilisons Subversion comme référentiel de code et Visual Studio 2010 comme IDE. Je sais que beaucoup de gens préconisent Mercurial et d'autres systèmes de contrôle de source distribués, mais à ce stade, je ne vois pas comment nous pourrions en bénéficier, mais je peux me tromper.

Notre principal problème est de savoir comment synchroniser les branches et le tronc principal.

Voici comment nous faisons les choses aujourd'hui:

1. Release new version (create automatically a tag in Subversion)
2. Continuez à travailler sur le coffre principal qui sortira le mois prochain

Et le cycle se répète tous les mois et fonctionne parfaitement. Le problème se pose lorsqu'une version de service urgente doit être publiée. Nous ne pouvons pas le libérer du coffre principal (2) car il est en cours de développement et il n'est pas suffisamment stable pour être libéré de toute urgence.

Dans ce cas, nous procédons comme suit:

1. Créez une branche à partir de la balise que nous avons créée à l'étape (1)
2. Correction d'un bug
3. Test et publication
4. Repousser le changement dans le coffre principal (le cas échéant)

Notre plus gros problème est de fusionner ces deux (branche avec principal). Dans la plupart des cas, nous ne pouvons pas compter sur la fusion automatique car, par exemple:

• de nombreux changements ont été apportés au tronc principal
• la fusion de fichiers complexes (comme les fichiers XML Visual Studio, etc.) ne fonctionne pas très bien
• un autre développeur / équipe a apporté des modifications que vous ne comprenez pas et que vous ne pouvez pas simplement fusionner

Donc, ce que vous pensez est la meilleure pratique pour garder ces deux versions différentes (branche et principale) synchronisées. Que faire?

Je pense que votre approche de la ramification et de la fusion est correcte, mais si le principal problème est que la base de code est assez instable, c'est sur cela que vous devez vous concentrer et minimiser.

La principale chose à garantir est que la base de code a une bonne séparation des préoccupations . Les dépendances entre les différents composants doivent être isolées et réduites. Cela devrait résoudre la majorité de vos problèmes. Il sera également utile de suivre des pratiques telles que le principe de responsabilité unique.

Si un changement architectural majeur doit se produire, il devrait avoir lieu dans sa propre branche, puis fusionné de nouveau dans le principal une fois entièrement testé et «stable» (dans des limites raisonnables). Cela peut être douloureux et difficile, mais cela devrait également être rare. Si vous disposez de bonnes pratiques de test, le risque est minimisé.

Il peut également être utile de passer à un système de contrôle de version distribué. Cela devrait vous donner un tronc stable, avec différentes fonctionnalités fusionnées à partir de différentes branches lorsqu'elles sont prêtes. Vous aurez toujours de la difficulté à fusionner si le code est trop interdépendant, mais vous aurez plus de contrôle.

En considérant cela sous un autre angle, envisagez également une communication accrue au sein de votre équipe. Organisez régulièrement des réunions standup de style agile. Demandez-vous où les membres de l'équipe sont assis et comment cela peut aider. Si une fusion complexe doit avoir lieu, ce n'est peut-être pas une si mauvaise chose - utilisez une approche de programmation par paires qui donnera de la compréhension aux deux parties.

J'ai tendance à voir les choses à peu près de la manière opposée:

• Le tronc doit toujours être du code prêt pour la production (après votre première version initiale, c'est-à-dire).
• Il devrait y avoir une branche de type développement qui fonctionne parallèlement au tronc, où se déroule votre développement mensuel. Chaque mois, en ce qui concerne le temps de sortie, celui-ci est fusionné dans le coffre, testé, puis publié.
• Les correctifs peuvent ensuite être facilement créés dans votre coffre et enregistrés, et toujours être déployés avec succès. Créez ensuite un correctif à partir du correctif et appliquez-le à votre branche de développement.

Bien sûr, ce flux de travail est beaucoup mieux adapté à quelque chose qui n'est pas SVN, car une bonne ramification et fusion est quelque chose de très pénible dans SVN, quel que soit votre flux de travail. D'après mon expérience, la fusion dans SVN devrait presque toujours être effectuée manuellement, car cela ne fonctionne tout simplement pas, et il n'y a pas vraiment de solution.

Dernièrement, j'ai préconisé une philosophie de «branche et fusion» comme dernier résultat. Je pense que c'est la triste vérité que traiter les fusions de code à partir de branches n'est pas un problème technique, mais c'est une tâche difficile sur le plan cognitif: je pense que c'est simplement que le cerveau humain ne suit pas suffisamment de détails pour le rendre facile. De plus, je n'ai pas encore vu de branchements et de fusions fonctionner dans la pratique. Une fois que le code est ramifié, l'expérience me dit que ce n'est rien d'autre que de la fusionner à nouveau.

Une approche disciplinée de libération principale fonctionne bien.

La ramification SVN n'est pas conçue pour être flexible. Je dirais que votre premier problème réside dans SVN; passer de cela ouvrira de nouvelles options.