Quel est votre workflow de déploiement d'applications Web préféré avec SVN ?

Question

Nous utilisons actuellement une configuration de déploiement quelque peu compliquée qui implique un serveur SVN distant, 3 branches SVN pour DEV, STAGE et PROD, promouvant le code entre elles via des correctifs, etc.Je me demande qu'utilisez-vous pour le déploiement dans une situation de petite équipe de développement ?

Answer 1

un tronc pour le développement et une branche (production) pour les éléments de production.

Sur ma machine locale, j'ai un VirtualHost qui pointe vers la branche principale, pour tester mes modifications.

Tout commit sur trunk déclenche un hook de validation qui effectue une exportation svn et une synchronisation avec l'URL de développement du serveur en ligne - donc si le site est stackoverflow.com, ce hook met automatiquement à jour dev.stackoverflow.com

Ensuite, j'utilise svnmerge pour fusionner les correctifs sélectionnés du tronc vers la production dans mes caisses locales.J'ai à nouveau un VirtualHost sur ma machine locale pointant vers la branche de production.

Lorsque je valide les modifications fusionnées dans la branche de production, encore une fois, un hook d'exportation SVN met à jour l'exportation de production (en direct) et le site est en ligne !

Answer 2

Quand je travaillais dans une petite équipe de développement (c'est-à-dire moi, un autre programmeur et le patron), c'était un gâchis assez chaotique.Cependant, nous avons constaté que l'attribution d'un processus de type « gardien » fonctionnait pour nous.

Le gardien était la personne qui avait fait le plus de travail sur l'application (dans ce cas, j'avais 2 projets que j'avais développés à partir de zéro, il en avait environ 4).

Fondamentalement, chaque fois qu'il devait travailler sur mes projets, il me prévenait qu'il était en train de travailler, je m'assurais que le référentiel était à jour et constructible, puis il le déroulait, apportait ses modifications, puis validait .Il m'informait que c'était fait, je démontais, construisais et déployais.S'il y avait des modifications dans la base de données, nous avions un dossier DB Change avec tous les scripts qui corrigeraient la base de données.

Il y a évidemment beaucoup de trous, mais le processus a fonctionné pour nous et nous a empêché de construire les uns sur les autres.

Answer 3

Je n'ai eu aucun problème avec l'organisation commune des balises/branches/tronc.

Le développement général continu se produit dans le tronc.

La maintenance d'une version en production s'effectue dans la branche de version appropriée.

Les modifications apportées à la branche de version qui sont toujours pertinentes pour le tronc sont fusionnées.

Lorsqu'une nouvelle version est prête à être déployée, elle est balisée à partir du tronc, puis une branche est créée à partir de cette balise.La nouvelle branche de version est extraite sur le serveur, parallèlement à la version actuelle.Quand il est temps de changer, les chemins sont jonglés ("mv appdir appdir.old && mv appdir.new appdir").

Les développeurs prenant en charge la version de production svn basculent ensuite leur copie de travail vers la nouvelle branche ou effectuent une nouvelle extraction à partir de celle-ci.

Answer 4

Trois branches, cela ressemble à du travail supplémentaire.

Les différences environnementales peuvent être gérées en ayant différentes versions des fichiers pertinents dans le coffre.c'est à dire.base de données.yml et base de données.yml.prod.Le processus de déploiement doit être respectueux de l'environnement et copier simplement les fichiers par environnement sur ceux par défaut.

Answer 5

Une simple branche de tronc contient le code le plus récent, puis coupez une branche à chaque fois que nous mettons en ligne.Cela semble fonctionner assez efficacement.Vous pouvez facilement accéder à la branche précédente chaque fois que la branche actuelle que vous avez coupée pour le système actif échoue.De plus, il est facile de corriger les bugs sur la branche qui est actuellement active, et comme la branche meurt effectivement lorsque vous en coupez une nouvelle, il n'y a qu'une seule branche réelle sur laquelle vous devez travailler (puis fusionner les correctifs de là vers la branche actuelle). branche en direct).

Answer 6

Nous n'utilisons pas de branches pour organiser des éléments liés au Web ;uniquement pour tester des choses expérimentales qui prendront beaucoup de temps (lire :plus d'une journée) pour réintégrer le coffre.Le tronc, dans le style « intégration continue », représente un état actuel (espérons-le) fonctionnel.

Ainsi, la plupart des changements sont directement affectés au tronc.Un serveur CruiseControl.NET se mettra automatiquement à jour sur une machine qui exécute également IIS et dispose de copies à jour de toutes les ressources supplémentaires du site disponibles, afin que le site puisse être entièrement et proprement testé en interne.Après les tests, les fichiers sont téléchargés sur le serveur public.

Je ne dirais pas que c'est l'approche parfaite, mais c'est simple (et donc adapté à notre personnel relativement petit) et relativement sûr, et fonctionne très bien.

Answer 7

Trunk contient la base de code de développement « primaire » actuelle.

Un développeur créera souvent une branche individuelle pour tout projet à moyen ou long terme qui pourrait épuiser la base de code principale et gêner les autres développeurs.Lorsqu'il aura terminé, il réintégrera le coffre.

Nous créons une version étiquetée chaque fois que nous transférons le code en production.Le dossier dans /tags est simplement le numéro de version.

Pour déployer en production, nous effectuons une exportation SVN vers Staging.Lorsque cela est satisfaisant, nous utilisons un simple rsync pour le déployer sur les clusters de production.

Answer 8

Je recommande fortement le livre (actuellement en version préliminaire) Livraison continue, qui décrit un processus complet de gestion de la livraison de logiciels, basé sur des principes d'intégration continue (entre autres).

Je n'aime pas du tout l'approche de branchement et de fusion, car elle peut devenir très compliquée et constitue un gaspillage considérable puisque vous finissez par consacrer du temps à des activités qui n'apportent réellement aucune nouvelle valeur.Vous avez déjà développé, testé et corrigé votre code une fois, pourquoi créer une situation (copier le code dans une autre branche) qui vous oblige à refaire ce travail ?

Quoi qu'il en soit, le moyen d'éviter les branchements et les fusions est de créer vos artefacts déployables à partir du tronc et de promouvoir les artefacts construits (plutôt que la source) au fur et à mesure qu'ils réussissent les tests, la préparation, etc.De cette façon, vous êtes sûr à 100 % que ce que vous mettez en production est le même que celui que vous avez testé.

Si vous disposez de différentes fonctionnalités qui peuvent devoir être publiées selon des calendriers différents, modifier votre approche de la façon dont vous les implémentez (rendre les fonctionnalités configurables, ou mieux encore modulaires) peut vous aider à conserver un seul tronc de développement.

Answer 9

Nous utilisons le branchement des versions - cela semble être plus efficace pour nous que le branchement des fonctionnalités que nous faisions.

Ne créez pas de branches différentes pour les différents environnements.

Answer 10

Personnellement, je travaille localement (développement), en ajoutant/corrigeant des fonctionnalités et quand je pense que c'est prêt, je m'engage sur le tronc (production).Sur le serveur de production, je fais juste une mise à jour svn.

Answer 11

Je travaille avec une situation similaire à celle que vous vivez actuellement.J’avais pour tâche de trouver une « meilleure » solution et celle-ci ressemblait à ce qui suit.

La branche live représente les serveurs dans leur état actuel.

Tout travail de développement doit être effectué dans une branche extraite de Live.Il peut s'agir d'un travail d'une demi-heure pour une seule personne ou d'un projet multi-équipe d'un an.Aussi souvent que l'on souhaite, les changements à vivre peuvent être fusionnés dans ces branches de développement.

Avant qu'un travail ne soit mis en ligne, les modifications apportées par le live sont à nouveau fusionnées et elles sont étiquetées comme une version potentielle.Cette version est testée sur l'environnement de test et si elle réussit les tests, le nouveau live est extrait de la balise.

Il est possible de fusionner plusieurs éléments de travail en une seule version si cela fonctionne mieux.

Cela signifie qu'il est assez simple de maintenir les branches de développement à jour avec Live et si un travail de développement est abandonné, il y a un minimum de rangement à faire.

Pour passer d'un projet à un autre, un développeur peut simplement basculer son environnement de travail local vers une autre branche.

L'un des problèmes que nous avons rencontrés avec le système tel que vous le décrivez est que DEV peut devenir obsolète avec PROD assez rapidement, vous ne développez donc pas contre le live et il n'est pas facile de repérer les dépendances croisées avant le stade.La solution ci-dessus résout ces problèmes tout en restant assez légère.