manutenção de diferenças de configuração entre dev e ambientes ao vivo durante a implantação do SVN

Question

Usamos o ExpressionEngine CMS (PHP) para criar websites. Para cada local, montamos um repositório Subversion e comprometer a instalação EE, bem como quaisquer modelos personalizados, imagens, javascript, etc, que são usados. Incluído no repositório é o arquivo que contém todas as variáveis ??de ambiente e o arquivo .htaccess.

Temos um servidor de desenvolvimento com uma cópia de trabalho do repositório atualizado via post-commit que usamos para desenvolver. Quando estamos prontos para liberar criamos uma filial em subversão, faça as alterações necessárias para o ambiente de produção, tag o número da versão, exportar o repositório, enviá-lo para um novo diretório no servidor ao vivo, e ligar simbolicamente os arquivos no lugar. A reversão é tão simples como criar um link simbólico de volta para a versão anterior.

O problema é que passo em que temos de modificar as variáveis ??de ambiente que precisam ser diferentes para os servidores dev e produção. Isso é coisa como (des) regras htaccess comentando que seria redirecionar para os lugares errados, trocar chaves de API do Google Map porque os domínios são diferentes, a execução de scripts que minimizem o javascript em um arquivo ofuscado para manter o tamanho e http conexões para baixo, etc .

A questão é como isso poderia ser mais automatizado? Nós gostaríamos de obter o procedimento de liberação para baixo para o mínimo. Eu estou familiarizado com a existência de ferramentas como Capistrano e fazer, mas eu não sei como eu poderia levá-los a modificar todos os arquivos necessários ... como você organizar uma coisa dessas? É este vale a pena gastar automatizar tempo quando isso acontece talvez uma vez a cada duas semanas?

Answer 1

Um monte de opções de configuração podem ser tratadas por ligar $ _SERVER [ 'HTTP_HOST'].

Por exemplo

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

Então, por questões .htaccess você pode definir um arquivo .htaccess alternativo em sua definição de vhost usando a diretiva AccessFileName:

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

Answer 2

Eu lidar com este problema adicionando arquivo de configuração para Subversion lista ignorar. Ele já foi abordada aqui na Stackoverflow: ver pergunta # 149485

Basicamente, eu só manter setup.default.php no SVN, e em cada instalação eu copiá-lo manualmente para setup.php que está na lista de ignorados. Isso impede que o arquivo a ser verificado de volta para o repo. Não são raramente muda para este arquivo e pode ser tratado como ocorre a exigência.

Answer 3

Outra alternativa é a ramificar os arquivos de configuração uma vez, em um ramo release, e, em seguida, marcá-los como editados no destino e, em seguida, usar um script de mesclagem que se lembrar de como fazer uma mesclagem de três vias. Se as alterações de configuração na fonte, então ele provavelmente vai gerar um conflito, que é uma coisa boa, porque você provavelmente precisará fazer mudanças similares no destino.

Assim, você mantém duas árvores que vão para a vida útil do projeto: o desenvolvimento e lançamento. Como as coisas amadurecem em desenvolvimento, você integrá-los sobre a liberação. Você pode ter um terceiro, QA, árvore, bem como, se você tem um processo de liberação mais envolvidos.

Quando você puxa uma nova versão, você copiar a partir da área de trabalho para a área de "release" (como uma fusão / integração), em vez de puxar um novo ramo. Se você também quiser um instantâneo-in-time da árvore liberação nesse ponto, em seguida, fazer um ramo separado / copiar / tag que você usa apenas para fins de arquivo.

Btw:. Esta é uma das áreas onde Perforce brilha - ele se lembra o que você já se fundiram, e nunca vai tentar fundir duas vezes

Answer 4

Temos de lidar com isso mantendo um diretório específico-config.

Assim, por exemplo, se você tem diferentes arquivos .htaccess e config.php entre dev e produção seriam mantidos em / trunk / config / {ambiente} /

Nós usamos scripts / nant formigas para criar pacotes de libertação, e os scripts têm uma tarefa de compilação para cada ambiente. Essas tarefas pegar os arquivos específicos de configuração.

-

Outro comentarista sugere para ligar HTTP_POST. Infelizmente, não posso comentar diretamente (não um representante de alto o suficiente). Usando HTTP_POST para determinar a configuração ambiental tem problemas de segurança em potencial já que o valor desta vem do cliente.