Numéro du cycle de développement Web SVN

Question

L'organisation pour laquelle je travaille actuellement utilise SVN pour développer des applications PHP. Notre cycle de développement a démarré de manière simple, faire un commit met à jour la racine web en utilisant le hook post-commit afin de voir les changements tout de suite. Nous avons rencontré un problème avec les fonctionnalités de développement empêchant les corrections de bogues et empêchant les fichiers fixes d'être déplacés en production et provoquant parfois des problèmes sur le serveur prod. J'ai donc introduit un schéma de «branchement de version» qui signifie que toutes les versions complètes sont copiées dans leur propre branche, donc toutes les modifications apportées à la production devaient se produire dans cette branche et un développement «à long terme» se produisait sur le tronc. L'idée de départ était de ne faire que des correctifs et de rendre le développeur responsable du transfert de ses propres mises à jour sur le tronc, mais après cinq instances de développeurs fusionnant aveuglément des changements entraînant une perte de données et un développement constant d'éléments à diffusion immédiate. branche de publication cette méthodologie a été abandonnée. Sachez que je suis confronté à une branche qui n'est pas synchronisée (puisque certaines personnes n'ont pas "compris" le concept de tronc/branche et se développent sur le tronc) avec les changements fusionnés dans le tronc à partir d'une branche privée créant le potentiel de plus de code perdu lors de la fusion de tous les changements du mois passé à partir de la branche de publication actuelle.

J'ai la chance de recommencer et de mettre en application un cycle de développement/publication correct du développement web. SVN semble être orienté vers le développement "release" (applications binaires), où dans ce cas nous pouvons passer une année complète sans déplacer le paquet complet vers la production. Dans ce contexte, voici ma question: Quel cycle de développement Web SVN et/ou schéma recommanderiez-vous pour cette situation? Est-ce que cela nécessite une révision complète de la méthodologie ou est-ce que je manque quelque chose de simple?

Merci pour vos idées!

Answer 1

Voici notre cycle de développement typique; nous sommes "psuedo agile"; et exécutez un cycle de publication de 2 semaines.

Tous les projets démarrent sur une branche depuis le tronc. Aucune exception.

Une fois le projet terminé, et efface la révision de code, le développeur reçoit le feu vert pour fusionner cette branche dans le circuit. De cette façon; aucun code qui n'a pas été minutieusement vérifié se retrouve sur le coffre. Nous utilisons CruiseControl pour une intégration continue, donc après un commit sur le tronc, si des tests échouent, le développeur est responsable de les corriger. Ces correctifs vont sur le tronc.

Une semaine avant la prochaine version; nous créons une "étiquette" de libération (essentiellement une autre branche) et l'envoyons au contrôle qualité. Si vous n'avez pas encore ramené votre code au tronc, il ne sortira pas avec la prochaine version. (Note importante: cette "balise" de version n'est jamais fusionnée au tronc.) Comme QA trouve des bogues; ils sont assignés au développeur. Quand le développeur les corrige; leurs modifications doivent être validées à la fois sur la balise Release et sur le joncteur réseau.

Lorsque le jour de la commercialisation arrive; nous lâchons tout sur cette étiquette. Dans le cas de correctifs postérieurs à la publication nous suivons les mêmes directives que lorsque nous sommes dans le cycle d'AQ, de cette façon si quelqu'un fusionne dans un nouveau projet vers le tronc après que la balise de lancement a été coupée; il ne se libère pas par inadvertance avec le correctif d'urgence.

Lather, rincer, répéter ...

Cela pourrait ne pas répondre à votre question en soi; mais j'espère que cela servira comme un bon point de vue extérieur de la façon dont vous pourriez vouloir mettre en place votre processus de développement. Ce n'était pas notre processus original, mais plutôt ce que nous avons mis au point au cours de la dernière année ou deux, et d'après mon expérience, il s'agit d'un pas en avant comme nous le faisions auparavant.

Si vous souhaitez des éclaircissements à ce sujet; laissez-moi un commentaire et je mettrai à jour si nécessaire.

Answer 2

Ceci est toujours difficile, quel que soit le système que vous utilisez. Je doute qu'il y ait de meilleures solutions que celle que vous avez utilisée auparavant. Peut-être passer plus de temps à éduquer vos collègues sur le concept?

Answer 3

Je sauvegarde Bart sur ceci; le problème est la formation. Vous devez faire en sorte que vos collègues utilisent correctement SVN avant que vos projets ne deviennent trop complexes pour être gérés. Votre schéma de branchement semble correct à partir de votre description, mais il est vrai qu'une personne qui ne suit pas le plan va le casser pour tout le monde.

Encore une fois, faites-le maintenant avant que vos projets deviennent plus complexes.

Answer 4

Je ne sais pas si vous les utilisez déjà mais je recommande fortement les branches de développement. Chaque nouvelle fonctionnalité/bogue a sa propre branche qui est copiée à partir du tronc (ou de la branche) auquel il doit éventuellement être fusionné. Tous les développements et les check-ins pour cette fonctionnalité ont lieu sur la branche devel. Une fois la fonctionnalité/correction de bugs terminée, le tronc est ensuite fusionné dans la branche de développement FIRST et après vérification et vérification de base (banc d'essai standard?), La branche de développement peut être fusionnée dans le tronc en sachant que tout doit être là-bas. La clé étant la fusion du tronc dans la branche devel pour détecter toute nouvelle modification de tronc, puis tester la branche devel avant de la fusionner vers le tronc. Si chaque changement a sa propre branche, les développeurs se lancent assez vite dans le mouvement.

ET comme d'autres l'ont déjà mentionné, l'éducation du personnel. Aucune exception à l'éducation du personnel et aucune exception à chaque changement ayant sa propre succursale. Les copies dans SVN sont bon marché et faciles donc il n'y a aucune vraie excuse pour une exception.

Answer 5

Le premier point de l'ordre du jour serait d'éduquer votre personnel sur le fonctionnement de SVN et la méthodologie qui le sous-tend. Peu importe l'élégance de votre projet, s'ils ne peuvent pas le suivre, ils ne le feront pas.

Je fais tout moi-même dans les branches 'Feature'. Ma mise en page est comme ceci:

branches/ 
    [feature branches] 
    stable/ 
tags/ 
    [all of our releases] 
trunk/ 

Tout ce qui touche plus de quelques fichiers, ou des travaux importants, se fait dans une branche de fonction. Les petites corrections de bugs ou le travail rapide se font directement dans le coffre. Tout au long du développement, les branches sont toutes synchronisées avec le tronc (le tronc est fusionné dans les branches tous les quelques jours). Lorsque le moment de la publication arrive, nous prenons toutes les fonctionnalités prévues pour la publication et les fusionnons dans le coffre. Une branche d'entité est fusionnée, vérifiée et, si elle est bonne, déplacée dans la branche stable. Laver, rincer, répéter pour toutes les branches caractéristiques. Une fois la version stable terminée, elle est étiquetée comme une version, et notre système de construction peut maintenant générer une production basée sur la nouvelle étiquette.

Si nous devons effectuer des réparations d'urgence qui entrent directement en production, le tag est extrait, corrigé et un patch est généré. Le correctif est appliqué au tronc, puis introduit dans Stable et toutes les nouvelles entités.