Je confirme pour capistrano multistage, vraiment très pratique ;) Pour ce qui est de l'infra tout dépend de ton app, si c'est une petite app tu peux poser le staging et la prod sur le même serveur.
Attention aux différents services. Comme le disait Olivier il peut y avoir des conflits. Redis est un bon exemple et vu que Resque et Sidekiq (entre autres) s'en servent il faut penser aux namespaces. Heureusement la plupart des outils proposent une option de config pour le namespace ;) Simon Courtois On 24 janv. 2013, at 15:36, Florian Dutey <[email protected]> wrote: > Pour une copie conforme, l'usage des VM est un gros plus. > Le serveur de staging sur la prod, je suis très partagé perso... Si t'as des > taches de fond gourmandes qui tournent, c'est x2 donc tu dois doubler les > capas de ton serveur de prod uniquement poru faire tourner un staging qui ne > sert à rien. > > Le schéma standard c'est serveur de pré-production et serveur d'inté continue > > Tu dev, tu pousses. > Ton serveur d'inté continue observe ton scm. Chaque fois qu'il il y a du > changement, il pull, il lance toute la suite de tests. > Si ca passe pas, mail a la team de dev (et autres plugin qui compte le > nombre de commit fails pour chaque user et qui établit un classement de la > honte par exemple). > Si ca passe, ca déploie en pré-prod et mail au PO (ou chef de projet) pour > l'informer (qui verra ensuite avec le client quand il jugera que c'est > opportun). > Quand on arrive au bout de la release, on tag et on teste le déploiement (les > fonctionnalités sont déjà testées normalement), cad migrations etc... sur un > env de staging qui, dans l'idéal est une copie conforme de la prod (dans > l'idéal). > > Ensuite on déploie sur la prod. > > > Le 24 janvier 2013 15:33, Olivier El Mekki <[email protected]> a écrit : > Oui tout à fait, je l'ai déjà fait. Que ce soit en utilisant > apache/passenger ou nginx/unicorn, ce n'est pas plus difficile que de > faire cohabiter deux sites webs sur un server. > > Pour le déploiement, capistrano à une extension multistage : > https://github.com/capistrano/capistrano/wiki/2.x-Multistage-Extension > > Ça te permet de faire : > cap deploy # deploy sur staging > cap production deploy # deploy sur production > > > Les seules difficultés que j'ai rencontrées ont été memcache et > delayed_job. Les service memcache des OS sont prévus pour faire tourner > une seule instance de memcache. Par simplicité, nous en voulions deux : > une pour staging et une pour production. Il a alors fallut en démarrer > une manuellement. > > Quant à delayed_job, il gère ses process non par PID mais par matching > du nom du process ... On a eu des surprises jusqu'à ce qu'on lui passe > des options pour prefixer les noms des process. > > On 09:26 Thu 24 Jan , Guirec Corbel wrote: > > @Olivier, penses tu que c'est faisable "simplement" avec EC2? > > > -- > Olivier El Mekki. > > -- > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > > > > > -- > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected]
