le maintien des différences de configuration entre dev et les environnements en direct pendant le déploiement de SVN

Question

Nous utilisons pour créer des sites Web CMS ExpressionEngine (php). Pour chaque site, nous avons mis en place un dépôt subversion et commettons l'installation d'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 par post-commit que nous utilisons pour développer. Lorsque nous sommes prêts à libérer, nous créons une branche dans la subversion, apportez les modifications nécessaires à l'environnement de production, balise le numéro de version, exporter le référentiel, le transférer à un nouveau répertoire sur le serveur en direct, et un lien symbolique des fichiers en place. Un rollback est aussi simple que de retour à la lien symbolique version précédente.

Le problème est que l'étape où nous devons modifier les variables d'environnement qui doivent être différentes pour les serveurs dev et de production. Ce sont des choses comme (un) commentent les règles htaccess qui redirigerez aux mauvais endroits, en échangeant des clés API Google Map, car les domaines sont différents, exécuter des scripts qui réduisent au minimum le javascript dans un fichier obscurcie pour maintenir les connexions de taille et de http vers le bas, etc. .

La question est de savoir comment cela pourrait-il être plus automatisé? Nous aimerions obtenir la procédure de libération vers le bas au strict minimum. Je connais l'existence d'outils tels que Capistrano et faire, mais je ne sais pas comment je pourrais les amener à modifier tous les fichiers nécessaires ... comment voulez-vous organiser une telle chose? Est-ce la peine de dépenser le temps d'automatiser quand il arrive peut-être une fois toutes les deux semaines?

Answer 1

Un grand nombre des options de configuration pourrait être traitée 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 .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 traite ce problème en ajoutant le fichier de configuration Subversion ignorer la liste . Il a déjà été abordé ici Stackoverflow: voir la question # 149485

En fait, je ne garde que setup.default.php dans SVN, et dans chaque installation copier manuellement à setup.php qui est sur la liste ignorer. Cela empêche le fichier à réintégrée dans la prise en pension. Il y a des changements rarement à ce fichier et peut être manipulé que l'exigence se produit.

Answer 3

Une autre alternative consiste à ramifier les fichiers de configuration une fois, dans une branche de sortie, et marquer ensuite les comme modifié sur la destination, puis utiliser un script de fusion qui se souviennent comment faire une fusion à trois voies. Si les modifications de configuration sur la source, alors il sera probablement générer un conflit, ce qui est une bonne chose, parce que vous avez probablement besoin de faire des changements similaires sur la destination.

Ainsi, vous gardez deux arbres vont pour la durée de vie du projet: le développement et la libération. Comme les choses arrivent à maturité dans le développement, vous les intégrez plus de libérer. Vous pouvez avoir un troisième, QA, arbre aussi bien, si vous avez un processus de libération plus impliqués.

Lorsque vous tirez une nouvelle version, vous copiez de la zone de travail dans la région « release » (comme une fusion / intégration), plutôt que de tirer une branche flambant neuf. Si vous voulez aussi un instantané en temps de l'arbre de sortie à ce moment-là, puis faire une branche distincte / copie / tag que vous utilisez uniquement pour des fins d'archivage.

BTW:. C'est l'un des domaines où Perforce resplendit - il se souvient de ce que vous avez déjà fusionné, et ne jamais tenter de fusionner deux fois

Answer 4

Nous traitons cela en maintenant un répertoire spécifique config.

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 des packages de libération, et les scripts ont une tâche de construire pour chaque environnement. Ces tâches ramassent les fichiers spécifiques de configuration.

-

Un autre intervenant suggère d'allumer HTTP_POST. Malheureusement, je ne peux pas commenter directement (pas un représentant assez élevé). En utilisant HTTP_POST pour déterminer la configuration de l'environnement a des problèmes de sécurité potentiels puisque la valeur de ce provient du client.