2010-07-19 5 views
2

Je travaille sur un site Web PHP où je viens d'ajouter un commutateur pour l'environnement dans lequel il fonctionne - development pour quand il fonctionne sur mon site local, et production quand il est en cours d'exécution sur l'hôte Web:Mercurial - conserver des dépôts de développement et de développement

<?php 
define('ENV','development'); 
//or 
define('ENV','production'); 

Je le site en VC avec Mercurial, et le plus souvent simplement déployer mon site avec hg push (le serveur exécute hg trop), mais, avec l'ajout de ce commutateur, la « production » Le site sera toujours différent du site "développement" en ce sens que la version déployée en direct sera toujours définie sur production au lieu de development.

Cela signifie que mon processus de déploiement va de

  1. Développer
  2. test
  3. hg commit -m "Made changes"
  4. hg push
  5. ssh host hg update
  6. Aller à 1.

à

  1. Développer
  2. test
  3. hg commit -m "Made changes"
  4. changement development-production
  5. `hg commit -m "dev -> prod"
  6. hg push
  7. ssh host hg update
  8. (plus tard :) Change production ->development
  9. hg commit -m "prod -> dev"
  10. Aller à 1.

Ce qui est évidemment pas grand.

Y a-t-il un moyen de garder une isolation de l'autre, de sorte que le site en direct soit toujours défini sur production et que ma copie locale soit définie sur development?

Répondre

3

Au lieu d'avoir un commutateur, avoir une branche de développement et une branche de production.

hg up prodbranch 
hg merge -r devbranch 
hg push 
ssh yourserver hg update prodbranch 
+0

Donc, dans ma branche de production, je mets du code spécifique à ce qui est vivant (comme les configurations de base de données), et sur ma branche de développement, je garde le code spécifique pour qu'il soit local? Et comment fonctionne la fusion entre les branches? Si je change de code qui affecte les deux branches, la fusion va-t-elle l'attraper? –

+0

Oui, il va, ce qui pose également un risque élevé de fusionner la mauvaise chose. Vous devriez avoir une meilleure stratégie pour garder vos paramètres de production/développement séparés plutôt que d'abuser de votre SCM. –

+0

@Austin: Euh, je garderais les configurations en dehors du repo de code. J'aurais 1 repo de configuration pour la production, et un epo de configuration 100% différent pour le développement. –

3

Si vous avez un serveur web Apache, vous pouvez le définir dans server/vhost/per-directory /.config htaccess:

SetEnv Deployment development 

Ou dans la production

SetEnv Deployment production 

et dans votre script:

define('ENV',$_ENV['Deployment']) 

Je suppose (comme il est généralement) que le serveur Web réel/config VirtualHost est à l'extérieur le code normal.

http://httpd.apache.org/docs/2.2/mod/mod_env.html#setenv

0

Avez-vous pensé à tout simplement pas mettre votre fichier conifguration sous contrôle de version?

+0

Eh bien, la partie configurée du site n'occupe vraiment qu'une très petite partie, et est travaillée dans le code, pas dans son propre fichier. J'ai pensé refactoring, mais même si je l'ai fait, ce n'est pas le point de la question (c'est l'exemple spécifique, et la principale raison de poser, mais pas le problème sous-jacent - avoir la même source altérée la même sémantique) –

Questions connexes