Est-ce que l'un d'entre vous utilise Rubber. D'après ce que je comprends il suffit de taper "cap rubber:create_staging" pour déployer une application et "cap rubber:destroy" pour la supprimer. Je pense que ça correspondrait à mes besoins.
C'est quoi le piège? Quelqu'un à déjà eu des problèmes avec ça? Si c'est si simple que ça en à l'air, pourquoi se compliquer la vie à faire différemment? Le 24 janvier 2013 09:53, Guirec Corbel <[email protected]> a écrit : > 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]
