localhost + staging + environnements de production?

Question

J'ai un site Web www.livesite.com qui est actuellement en cours d'exécution. J'ai développé une nouvelle version du site sur ma machine locale avec http://localhost et j'ai ensuite passé mes modifications avec svn sur www.testsite.com où je testerais le site sur le serveur livesite.com mais sous un autre domaine (c'est le même environnement comme le site en direct mais sous un domaine différent).

Maintenant, je suis prêt à publier la nouvelle version sur livesite.com. Faire la première fois est facile, je pourrais simplement copier & coller tout de testsite.com à livesite.com (pas sûr que c'est la meilleure façon de le faire). Je veux garder testsite.com comme site de test où j'appuierais les mises à jour, les testerais et une fois satisfait passer à livesite.com mais je ne suis pas sûr comment faire cela après le lancement du nouveau site. Je pense que copier le répertoire entier est la bonne façon de le faire et cela va casser les opérations des utilisateurs actuels sur le site livesite.com. Je veux aussi garder mon histoire svn sur testsite.com. Quelle est la bonne façon de le faire avec SVN? Merci beaucoup!

Answer 1

D'autres réponses mentionnant Hudson ou Weploy sont bonnes.Ils couvrent plus de problèmes que ce qui suit. Cela dit, ce qui suit peut être suffisant.

Si vous pensez que c'est exagéré, voici la façon de faire du pauvre avec SVN et un peu sysadminning créatif. Créez un lien symbolique avec votre document proudction et non un répertoire réel. Signifie que vous avez quelque chose comme ceci:

/var/www/myproject-1-0-0 
/var/www/myproject-1-1-0 
/var/www/myproject-1-1-1 
/var/www/html -> myproject-1-1-1 

Cela signifie que vous pouvez vérifier le code sur la production (par exemple, myproject-1-1-2) sans écraser des choses servi. Ensuite, vous pouvez passer codebases quasi instantanément en faisant quelque chose comme:

$ rm html && ln -s myproject-1-1-2 html 

Je recommande de ne pas faire plus d'une exportation svn checkout/svn de votre coffre sur la zone de production. Au lieu de cela, créez une branche à l'avance (nommez-la quelque chose comme myproject-X-Y-Z). De cette façon, si vous avez besoin de faire quelques ajustements très stressants du code de production, vous pouvez le renvoyer à la branche, et le fusionner au coffre une fois le feu éteint)

Je le fais beaucoup, et ça marche plutôt bien. Cependant, il a quelques inconvénients majeurs:

Principalement, vous devez gérer les migrations de base de données, ou d'autres scripts de mise à niveau, tout seul. Si vous avez des scripts (plain-old-SQL, ou quelque chose de plus impliqué), vous devez réfléchir à la meilleure façon de les exécuter. Le temps d'arrêt de l'espoir-juste-une-minute pourrait ne pas être une mauvaise idée. Vous pouvez garder un "site de maintenance" autour de (/ var/www/mainenance), et pointer le lien symbolique pendant quelques instants si nécessaire. Cette méthode n'est pas aussi cool que Weploy, par exemple, mais pour des projets relativement petits (fonctionnant sur un seul serveur, avec des bases de données pas très volumineuses), c'est souvent assez bon et simple.

Answer 2

Ma réponse va compliquer les choses un peu, mais voilà:

Je pour ce type de scénario utiliser Hudson.

Hudson permettra pour vous d'avoir un déploiement automatique /nettoyer le répertoire courant sur/ajouter de nouveaux processus de svn. Vous pouvez alors vous soucier du développement et moins de jongler et de déployer d'un endroit à un autre.

L'inconvénient est que vous avez besoin d'apprendre un peu sur la façon de configurer Hudson et comment faire lui de travail pour vous.

Comment démarrer avec PHP for Hudson

Je pense que vous devriez sur la bonne voie, un peu de travail comme je l'ai dit, mais est payant plus tard.

Answer 3

Si seul le code côté serveur change, il est possible que vous puissiez simplement copier le code et que tout ira bien. Mais même là, vous devez penser à la possibilité de personnes à mi-interaction. Si le code côté client change, en particulier si vous utilisez fortement ajax, vous devrez demander aux utilisateurs actuels de recharger leurs pages. Si la base de données change également, vous devez vous assurer qu'aucune transaction de base de données ne se produit au moment où vous appliquez les scripts de modification de la base de données.

Dans tous les cas, et indépendamment du fait que vous utilisiez un outil d'intégration continue, je crois qu'il est plus sûr de faire des temps d'arrêt pour appliquer ces changements. Une des raisons pour lesquelles les gens ont l'autocollant «bêta» sur leurs sites est qu'ils peuvent déconnecter tout le monde et tout fermer pour appliquer les changements sans préavis. Tant qu'ils ne le font pas très souvent, ils peuvent s'en tirer aussi. Une fois que vous n'avez plus de version bêta, l'application de changements devient une cérémonie au cours de laquelle vous commencez à annoncer des semaines d'arrêt à l'avance, puis une fenêtre de 30 minutes à quelques heures pour appliquer tous les changements. Pour les tâches sous-jacentes telles que le correctif des failles de sécurité dans le système d'exploitation ou le logiciel système, l'ajout de matériel, les temps d'arrêt peuvent être évités s'il y a équilibrage de charge et les correctifs sont appliqués un par un.