Besoin de conseils ou de pointeurs sur les stratégies de gestion des versions

Question

Je m'occupe d'un système basé sur le Web interne (Java, JSP, Mediasurface, etc.) qui est constamment utilisé (24/5).

Les utilisateurs lèvent des tickets pour des améliorations, des corrections de bugs et d'autres changements métier. Ces problèmes sont validés individuellement et attribués à l'un des trois ou quatre développeurs.

Une fois le problème terminé, il est généré et le code est uniquement validé par SVN. Les fichiers modifiés (modèles, html, classes, jsp) sont ensuite copiés sur un serveur de dev et validés dans un référentiel différent d'où ils sont extraits sur le serveur UAT pour être testés. (cela nécessite souvent le redémarrage du service Tomcat et parfois le service Mediasurface).

Les utilisateurs testent puis rejettent ou approuvent la version. S'il est approuvé, les fichiers édités sont extraits sur le serveur Live et le même processus que pour l'UAT.

En cas de rejet, le développeur effectue les modifications appropriées et recommence le processus de validation.

Tout cela est fait manuellement sans beaucoup de contrôle. Lorsque des développeurs différents travaillent sur des fichiers similaires, les modifications sont parfois écrasées par des builds sur du code non synchronisé. Dans d'autres cas, les modifications dans UAT sont déplacées pour vivre en erreur car elles sont mélangées dans des fichiers associés à une version validée. Je voudrais passer à un processus plus contrôlé et automatisé où tous les fichiers de code source et de sortie sont conservés dans SVN et libérés en Dev, UAT et Live gérés par un système CI (Nous avons TeamCity en interne pour notre. Applications NET).

Ma question est sur la façon de gérer les versions de plusieurs changements où certains seront signés et déplacés et d'autres rejetés et retournés au développeur. Les modifications peuvent concerner des fichiers qui se chevauchent et la fusion de chaque version en Release Branch signifie que les modifications rejetées doivent être supprimées de la branche.

Y at-il un moyen de gérer cela en utilisant SVN et CI ou devrais-je simplement vivre avec le système actuel.

Answer 1

Il me semble que l'annulation des modifications apportées à la branche Release me semble être une pratique normale dans votre cas, ce qui ne me semble pas approprié. Une chose que je trouve un peu surprenante est que pourquoi les utilisateurs testeraient-ils les changements et rejetteraient ou approuveraient la version? Tester à mon humble avis des changements et s'assurer qu'il résout les problèmes soulevés par les utilisateurs devrait être la tâche d'une équipe de test. Les utilisateurs ne sont pas des testeurs. S'il y a une équipe de test, vous pouvez avoir une branche de test ( (disons) où les corrections/changements sont poussés, et l'équipe de test utilise cette branche pour tester et qualifier les changements. Une fois que les modifications sont qualifiées par l'équipe de test, vous pouvez envoyer les modifications au Release Branch (par exemple) et effectuer le déploiement à partir de là. Même avec cette approche, il y aura des chances que les utilisateurs trouveront des problèmes avec les changements apportés, mais avec l'équipe de test effectuant les tests internes, le besoin de restauration deviendra une exception plutôt que la norme.

Answer 2

Je pense à la fonctionnalité de branchement, pas quelque chose que j'essaierais d'utiliser Subversion.

Fondamentalement, vous créez une branche pour chaque problème. Cette branche peut être créée, déployée et testée par des utilisateurs ou des testeurs. Si le correctif n'est pas accepté, vous pouvez continuer à améliorer le correctif sur la branche.

Si le correctif est accepté, vous devez toujours l'intégrer avec d'autres correctifs ou modifications en attente avant de pouvoir réellement libérer une forme ou un formulaire. Vous pouvez faire deux routes ici, vous pouvez intégrer le correctif sur la version actuellement en production pour créer une 'version de maintenance' ou vous pouvez simplement fusionner la 'branche fixe' avec la ligne principale/le tronc pour qu'elle soit libérée avec quelle que soit la prochaine version du coffre. Lorsque vous travaillez avec des versions de maintenance, vous devez faire preuve d'une grande prudence et ne pas oublier de fusionner les modifications apportées au réseau à un moment donné après l'acceptation ou après avoir obtenu l'accord des testeurs. Si ce n'est pas le cas, vous risquez de souffrir de bugs récurrents lorsque le tronc sera libéré plus tard.

Toutes les formes d'intégration peuvent nécessiter des tests supplémentaires; le correctif a pu être OK dans l'isolement, mais peut-être ne fonctionne pas très bien lorsqu'il est intégré avec tous les changements les plus récents du système. Si l'intégration concernée fusionne et qu'il y a peut-être eu des erreurs là aussi. En gardant cela à l'esprit, je m'en tiendrai à la négociation des communiqués. Les testeurs doivent tester les versions, et non les corrections individuelles isolément. La recherche et la résolution d'un problème ne signifient pas toujours qu'il doit être déployé instantanément. Parfois, vous pouvez négocier avec votre client; "Est-ce OK si nous publions ce correctif avec notre prochaine version régulière?".

L'ensemble de la comptabilité et de l'administration des chances, des correctifs et des versions hors bande devient très complexe très rapidement, je l'éviterais autant que possible. Si vous avez 4 correctifs et 1 n'est pas encore OK et les 3 autres peuvent attendre ... aller pour cette route.

Answer 3

Nous avons décidé d'adopter une approche multi-flux. Fondamentalement, chaque développeur travaille sur une nouvelle branche pour chaque changement et lorsque le changement est fusionné dans le flux Dev, il est surveillé par TeamCity et l'application est créée et libérée sur le serveur Dev pour les tests d'intégration.

Si cela réussit, les modifications sont fusionnées de la branche d'origine au flux UAT. Encore une fois, ceci est publié par TC sur le serveur UAT.

Une fois déconnecté, le changement est de nouveau fusionné de la branche d'origine dans le flux en direct et TC le publie sur le serveur live.

Il convient de noter que le flux pertinent doit être fusionné dans la branche avant chaque publication pour permettre le test par le développeur.

Il s'agit d'un processus un peu long, mais comme nous sommes loin d'être un département de test, et que je puisse convaincre l'entreprise de considérer les sprints ou d'autres processus de publication périodiques, nous devrons vivre avec.

Un grand merci pour tous les commentaires et suggestions ci-dessus.