maintien des différences de configuration entre les environnements de développement et en direct lors du déploiement à partir de SVN

Question

Nous utilisons le CMS ExpressionEngine (php) pour créer des sites Web. Pour chaque site, nous mettons en place un référentiel subversion et validons l'installation EE ainsi que tous les modèles personnalisés, images, javascript, etc. qui sont utilisés. Inclus dans le référentiel est le fichier contenant toutes les variables d'environnement et le fichier .htaccess.

Nous avons un serveur de développement avec une copie de travail du référentiel mis à jour via post-commit que nous utilisons pour développer. Lorsque nous sommes prêts à publier, nous créons une branche dans subversion, apportons les modifications nécessaires à l'environnement de production, marquons le numéro de version, exportons le référentiel, le téléchargeons dans un nouveau répertoire sur le serveur live et symlink les fichiers. Une restauration est aussi simple que de revenir à la version précédente.

Le problème est cette étape où nous devons modifier les variables d'environnement qui doivent être différentes pour les serveurs de développement et de production. C'est un truc comme (dé) commenter les règles htaccess qui redirigeraient vers les mauvais endroits, en remplaçant les clés google map API parce que les domaines sont différents, en exécutant des scripts qui minimisent le javascript dans un fichier obfusqué pour garder la taille et les connections http La question est de savoir comment cela pourrait-il être plus automatisé? Nous aimerions que la procédure de libération soit la plus stricte possible. Je connais l'existence d'outils tels que Capistrano et Make mais je ne sais pas comment je pourrais les amener à modifier tous les fichiers nécessaires ... comment organiseriez-vous une telle chose? Est-ce que cela vaut la peine de passer du temps à automatiser quand cela arrive peut-être une fois toutes les deux semaines?

Answer 1

De nombreuses options de configuration peuvent être traitées en activant $ _SERVER ['HTTP_HOST'].

Par exemple

switch ($_SERVER['HTTP_HOST']) { 
    case 'developement.domain.com': 
     $api_key = "dev environment api key"; 
     break; 
    default: 
     $api_key = "live environment api key"; 
} 

Ensuite, pour les questions de .htaccess vous pouvez définir un fichier .htaccess autre dans la définition de votre vhost en utilisant la directive AccessFileName:

<VirtualHost *:80> 
    ServerName sitename 
    AccessFileName .htaccess-dev 
</VirtualHost> 

Answer 2

Je résous ce problème en ajoutant le fichier de configuration à Subversion ignorer la liste. Il a déjà été abordé ici Stackoverflow: see question #149485

Fondamentalement, je ne garde setup.default.php dans SVN, et dans chaque installation, je copier manuellement à setup.php qui est sur la liste ignorer. Cela empêche le fichier d'être réintégré dans le repo. Il y a rarement des changements à ce fichier et peuvent être manipulés au besoin.

Answer 3

Une autre alternative est à la branche les fichiers de configuration une fois, dans une branche de publication, puis marquez-les comme modifiés sur la destination, puis utilisez un script de fusion qui vous rappelle comment effectuer une fusion à trois. Si la configuration change sur la source, il y aura probablement un conflit, ce qui est une bonne chose, car vous devrez probablement faire des changements similaires sur la destination.

Ainsi, vous gardez deux arbres pour la durée de vie du projet: développement et libération. Au fur et à mesure que les choses évoluent, vous les intégrez pour les libérer. Vous pouvez également avoir un troisième arbre, QA, si vous avez un processus de validation plus complexe.

Lorsque vous tirez une nouvelle version, vous copiez de la zone de travail vers la zone de "libération" (en tant que fusion/intégration), plutôt que de tirer une nouvelle branche. Si vous voulez également un instantané de l'arborescence de version à ce stade, créez une branche/copie/balise distincte que vous utilisez uniquement à des fins d'archivage.Btw: c'est l'une des zones où Perforce brille - il se souvient de ce que vous avez déjà fusionné, et ne tentera jamais de fusionner deux fois.

Answer 4

Nous traitons cela en maintenant un répertoire spécifique à la configuration.

Ainsi, par exemple si vous avez différents fichiers .htaccess et config.php entre dev et production, elles seraient maintenues dans/trunk/config/{environnement}/

Nous utilisons des scripts de fourmis/de Nant pour créer la libération packages, et les scripts ont une tâche de construction pour chaque environnement. Ces tâches récupèrent les fichiers spécifiques à la configuration.

-

Un autre intervenant suggère d'allumer HTTP_POST. Malheureusement, je ne peux pas commenter directement (pas assez haut rep). L'utilisation de HTTP_POST pour déterminer la configuration de l'environnement présente des problèmes de sécurité potentiels puisque la valeur provient du client.