Donc, si je comprend bien, il vaut mieux que j'utilise juste Capistrano que Rubber? Il va falloir que je créé un sous domaine et que je fasse des trucs qui me tentent vraiment pas... J'aurais aimé éviter ça. C'est ça que j'aime avec Heroku. J'aurais pu créer un autre autre application qui ne m'aurait rien couté et faire une mise en prod par la suite le tout en quelques lignes de commandes. Ça me fait ch.... Enfin bon, faut bien le faire.
Le 24 janvier 2013 09:47, Simon Courtois <[email protected]> a écrit : > 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] > > > -- -- 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]
