Ça, c'est le principe de la machine de développement. Quand une feature arrive sur staging, c'est qu'elle est prête à être shipped (rien n'empêche en parallèle d'avoir une machine de test si tu as besoin de faire des stress tests sur machine similaire à la prod, mais c'est quand même un cas relativement rare pour la plupart des apps).
On 15:23 Thu 24 Jan , Geoffroy Couprie wrote: > Le staging sur le même serveur que la prod, ça élimine l'avantage du > serveur de staging qu'on peut exploser tranquille... > Le 24 janv. 2013 15:20, "Olivier El Mekki" <[email protected]> a écrit : > > > C'est justement capital que ce soit sur le même server, sinon ça met en > > échec le principe de copie conforme :) > > > > Il y a plein de problème qui peuvent survenir en dehors de l'applicatif > > même : package système manquant, mauvaise configuration d'un server de > > mail, service censé tourner mais coupé, you name it. Tu ne peux réaliser > > cela que si ton env staging est sur le même server que l'env production. > > > > On 09:17 Thu 24 Jan , Guirec Corbel wrote: > > > C'est un peu à ce que je pensais quand je créé une nouvelle instance de > > > serveur EC2. Ça créé un environnement pareil à mon prod. Je souhaite le > > > supprimer juste après pour sauver des coûts. > > > > > > Le 24 janvier 2013 09:14, Olivier El Mekki <[email protected]> a écrit > > : > > > > > > > Hello, > > > > > > > > Généralement, pour éviter ce genre de problèmes, on utilise un > > > > environement de staging. Il s'agit d'un environement qui est une copie > > > > de l'env production, installé sur le même server, mais sur un autre nom > > > > de domaine ( par exemple : staging.ton_domaine.com ). > > > > > > > > L'env staging a sa propre db, régulièrement sync depuis l'env > > > > production, et son propre fs (tu peux sync les fichiers uploadés de > > > > production, également). > > > > > > > > L'idée est d'avoir une copie conforme de production pour tester les > > > > nouvelles features en conditions réelles, ce qui permet de voir tout de > > > > suite ce genre de problème, sans avoir de down. C'est aussi un bon > > moyen > > > > pour faire valider les features avant de les releases, quand tu > > > > travailles à plusieurs. > > > > > > > > > > > > On 09:08 Thu 24 Jan , Guirec Corbel wrote: > > > > > ¡Hola Amigos! > > > > > > > > > > Mardi j'ai fait une mise en prod qui à totalement craché mon > > application. > > > > > J'ai eu des problèmes avec mes assets. J'ai dû accéder en SSH à mon > > > > serveur > > > > > et faire des modifs en prod. Pour couronner le tout, mon internet > > > > plantait. > > > > > C'était super lent. Bref, une horreur. Je veux absolument éviter ça. > > > > > > > > > > Actuellement j’utilise Amazon EC2. J'ai vu qu'il existait Rubber. Ça > > a > > > > > l'air cool. Je voudrais automatiser ce processus : > > > > > > > > > > 1. Faire passé mes specs. Arrêter si ça passe pas et continuer > > sinon; > > > > > 2. Compiler mes assets; > > > > > 3. Créer un nouveau serveur EC2; > > > > > 4. Envoyer mon code; > > > > > 5. Faire un db:migrate. > > > > > > > > > > En suite je fais mes test voir si tout va bien et j’exécute ce > > processus > > > > : > > > > > > > > > > 1. Envoyer mon code en prod; > > > > > 2. Faire un db:migrate; > > > > > 3. Supprimer le serveur de test. > > > > > > > > > > Selon vous, quel est le meilleur moyen de faire ça? Utiliser > > Capistrano? > > > > > Comment vous faites? > > > > > > > > > > > > > > > J'aimerai savoir quels sont les bonnes pratiques pour la mise en > > prod en > > > > > sachant que j'ai pas les moyens d'avoir 36 serveurs. Je travail > > > > > "bénévolement" et tout l'argent viens de ma poche. Même 30 euros par > > moi > > > > je > > > > > trouve ça cher. > > > > > > > > > > Question bonus : est-ce que amazon EC2 c'est vraiment le mieux pour > > un > > > > > "micro site"? > > > > > > > > > > > > > > > J'avoue n'avoir aucune expérience la dedans... > > > > > > > > > > > > > > > Merci! > > > > > > > > > > -- > > > > > -- > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > -- > > > > 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] > > > > > > > > > > > > -- > > 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] > > -- 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]
