Comment faites-vous le suivi de ce que vous avez sorti en production?

Question

typiquement deploy dans la production ne comporte pas seulement une mise à jour simple de code source (build) mais nécessite beaucoup d'autres tâches importantes comme, par exemple:

1. scripts Db
2. fichiers de configuration (panachées de test \ production)
3. lot pour planifier
4. exécutables pour passer au bon chemin
5. etc etc.

Dans notre société, nous suffit d'envoyer un e-mail à une « adresse envoi.Décharge » décrivant les tâches dans l'ordre, qui changeSet doivent être publiés (TFS), dont SP doivent être mis à jour, les scripts db et ainsi de suite.

Je crois qu'il n'y a pas un outil magique qui fait ces tâches automagiquement dans l'ordre, rollback inclus; mais il y a probablement quelque chose de mieux que le courrier électronique qui permet de garder une trace des versions en production.

Avez-vous des outils pour suggérer ou pratiques à partager?

Answer 1

Lorsque plusieurs tâches sont nécessaires pour appuyer un déploiement complet du projet (et qui est souvent le cas, dans mon expérience), je suggère d'utiliser un build/outil de déploiement. J'ai déjà utilisé Ant dans le passé avec beaucoup de succès, mais je connais d'autres qui ne jurent que par Capistrano, Maven et d'autres.

Utiliser Ant, j'ai écrit un script qui:

1. Tirez sur la révision spécifique que je voulais de mon VCS
2. Créer une archive tar du répertoire cible sur la machine distante (dans le cas où un rollback était nécessaire)
3. Créer un fichier de vidage MySQL de la base de données (également à des fins d'annulation)
4. Supprimer le répertoire distant et SSH le nouveau contenu juste tiré de la VCS
5. Effectuer diverses autres journal opérations istical (réglage perms de fichiers, propriété, etc.)
6. Créer une branche de sortie sur le VCS se
7. Créer une étiquette avec les informations de version appropriée, donc j'ai toujours eu un aperçu de la base de code à ce moment du déploiement.

espoir qui aide certains. J'ai écrit quelques articles sur ce sujet qui pourraient (ou non) être utiles. Ils sont datés maintenant, mais l'information générale devrait toujours être assez solide.

• Introductory thoughts
• Details of how I use Ant for deploying--including scripts

Answer 2

Que diriez-vous quelque chose comme SVN? Vous pouvez mettre tout votre code dans un référentiel, puis, lorsque vous êtes prêt à sortir de la production, faites passer votre test de test. Ensuite, vous aurez des révisions très spécifiques avec des informations sur ce qui s'est passé. SVN garde la trace de tout cela.

Answer 3

Vous pourriez être intéressé par le site Web Team Foundation Build Recipes, qui met en valeur des scripts de compilation développée en utilisant la bibliothèque des tâches de la DDC et la bibliothèque MSBuildTasks