Conseils de déploiement en plusieurs étapes?

Question

Quelles sont les meilleures pratiques et la théorie générale du déploiement en plusieurs étapes pour les applications Web?

Je suis particulièrement intéressé par le déploiement des applications en utilisant Rails Git, Capistrano et passager, et je l'ai trouvé des postes qui traitent les écrous et boulons du processus:

• Capistrano: Multistage
• Introducing AutoTagger

Quelles considérations dois-je prendre en compte pour chaque étape (test, mise en scène, production)? Les étapes doivent-elles être déployées sur différents serveurs physiques? Des conseils ou des conseils sur le déploiement en plusieurs étapes? Des chicots que je devrais surveiller?

mieux,

Jacob

Answer 1

Il est préférable d'avoir deux environnements de serveurs différents: la mise en scène et la production. J'ignore toujours l'environnement de test. L'environnement de test agit comme la production, mais annule la base de données lorsque vous avez terminé. L'exécution simultanée sur le même serveur peut avoir un impact négatif sur les performances et la stabilité de l'environnement de production. La mise à niveau d'une gemme à tester dans l'environnement de transfert peut affecter négativement la production et vous faire perdre du temps.

Vous devez être très vigilant que les mêmes versions de gem sont sur les deux serveurs. Cela peut créer des problèmes si une version d'une application fonctionne en mise en scène mais n'est pas en production à cause de ce genre de divergence.

J'ai toujours une fenêtre de console ouverte qui est prête à annuler le dernier déploiement en cas de problème. Il n'y a vraiment pas beaucoup plus au processus que cela. Épargnez-vous de l'argent et achetez le serveur de mise en scène le moins cher que vous pouvez. Vous êtes le seul à l'utiliser, n'est-ce pas? Assurez-vous simplement qu'ils proviennent du même fournisseur.

Answer 2

J'ai toujours viens de créer des tâches de cap pour chaque cible de déploiement et les ont utilisés sur la ligne de commande:

# deploy.rb 
task :stage do 
    server 10.0.0.1 ... 
end 

> cap stage deploy 

Vous pouvez également définir personnaliser des tâches à l'intérieur de chaque tâche cible, comme un Deploy qui fait le nettoyage dans mise en scène, mais ne pas en production. Étant donné que ces tâches cibles de déploiement sont rarement très importantes, je n'ai jamais vraiment vu l'intérêt d'installer les extensions de cap pour plusieurs étapes, mais je suppose que les situations des autres peuvent être différentes. Je pense que la production devrait être séparée de vos autres environnements, sinon il y a un risque que des processus mal agencés en staging ou similaire puissent affecter les performances de production.

Parfois, je définis des tâches de plafonnement pour plus de commodité lors de la mise en scène, par exemple pour dynamiter la base de données et la recharger à partir du cliché de production le plus récent. Ces tâches doivent vérifier leur cible de déploiement via une variable définie ou similaire et refuser de se présenter à la production comme une assurance contre une faute de frappe de fin de soirée.

Il est tentant de mettre beaucoup de comportement personnalisé dans votre fichier deploy.rb, mais j'ai trouvé que cela a tendance à se réduire et à nécessiter beaucoup d'efforts de maintenance en fonction de l'environnement ou de l'API.

Une autre pratique que j'ai vu avec des environnements plus grands est d'avoir un compte shell avec un checkout qui suit la branche stable spécifiquement mis en place pour agir comme le point de contrôle capistrano. Vous ssh dedans et exécutez les commandes de cap là au lieu de localement. Cela peut aider à éviter les problèmes où le fichier deploy.rb de votre commande locale comporte des modifications que vous n'êtes pas prêt à utiliser avec le déploiement en production. C'est moins un problème avec git vs svn, mais il faut quand même faire attention à ce que leur déploiement.rb local est au moment où ils exécutent les commandes cap. Heroku rend vraiment ces choses faciles ces jours-ci, et EY et d'autres ne sont pas très loin derrière.

Answer 3

Nous utilisons le déploiement capistrano à plusieurs étages avec beaucoup de succès depuis plus d'un an. Le système sépare les fichiers de déploiement de chaque étape de manière presque identique aux fichiers d'environnement Rails. C'était très facile à installer et à gérer.