Como posso gerir a produção / teste / desenvolvimento de informações de configuração utilizando a subversão?

Question

Eu estou trabalhando em um aplicativo web / cliente combinado que tem ramificações para a produção, teste e desenvolvimento. Eu estou usando svn pós cometer ganchos para implantar atualizações para os servidores de produção e teste. O aplicativo cliente precisa apontar para diferentes URLs, dependendo da produção, teste ou desenvolvimento. Como posso gerenciar isso usando subversão? Opções Pensei são:

Opção 1
Manter um arquivo com detalhes específicos do ramo que nunca é mesclados entre os ramos.

Esta opção é mais fácil a partir de uma perspectiva de gestão de construção, mas é propenso a erro, pois eu tenho que lembrar a ignorar que a mudança cada vez que uma mesclagem é executada.

Opção 2
Criar produção, teste e desenvolvimento constrói do cliente não importa em qual ramo, e contar com ganchos SVN para puxar para baixo os binários corretos.

Como você lida com isso? Alguma idéia melhor?

Answer 1

A minha preferência é não verificar nos arquivos de configuração específicos do projeto para o controle de origem, mas sim manter o conteúdo de variáveis ??de ambiente e outros aspectos de configuração em uma pasta comum (no controle de origem). Os arquivos de configuração são então gerados como parte da compilação local, automação de construção, ou scripts de implantação, dependendo do que um determinado projeto, solução, necessidade poder ambiente em um determinado momento. Isso pode ser feito com arquivos simples de texto, modelos XML, ou algo mais complexo como o mecanismo de exibição faísca dependendo de suas necessidades. Você também pode fazer isso por convenção se modelagem é mais complexo do que você precisa (e normalmente é). Desta forma, não importa onde você estiver implantando o código também pode definir uma configuração de ambiente específico.

Um exemplo de por convenção é para definir seções de configuração personalizada em seus arquivos de configuração primárias (de configuração web, configuração de aplicativos, etc.). Você pode então armazenar uma conexão de cadeias de development.config, uma conexão de cadeias de integration.config, uma conexão de cadeias de testing.config, uma conexão de cadeias de pré-production.config, e uma conexão de cadeias de produção. config na sua fonte primária (ou pasta comum). O processo de compilação, então, solte o arquivo de configuração corda conexões apropriado renomeá-lo para simplesmente conexão de strings.config.

Generating pelo modelo que você também teria seções de configuração personalizada com os arquivos específicos de configuração mesmo ambiente, mas em vez de renomeá na implantação você pode simplesmente reescrever uma seção do arquivo de base de configuração diretamente com o nome do arquivo de configuração apropriada.

Manter os seus arquivos de configuração fragmentada pelo ambiente que proporciona-lhe uma grande flexibilidade, especialmente uma vez que você começar a gerir muitos sites que usam o mesmo ou similar estilo de configuração. Não importa o que, porém, a sua configuração deve ser ditada por algum aspecto de seu ambiente automatizado!

Answer 2

O aplicativo mantém um diretório separado com arquivos de configuração para cada ambiente implantado. Quando o servidor de compilação executa a tarefa de implantar em um ambiente específico Saiba qual diretório para puxar os arquivos de configuração de. O ponteiro para o diretório correto é parte da definição de compilação para o servidor de compilação (no nosso caso Pulso). Que se ramificam o código é construído a partir para essa tarefa de pulso também é parte da especificação de tarefas. Isso faz com que a decisão independente servidor implantação do ramo de modo que lançamos novos servidores versões e bancos de dados pode ser reaproveitado.

+ dev-server
+---jdbc.properties
+---build.properties
+ test-server
+----jdbc.properties
+---build.properties

Os arquivos de configuração não são ramificadas com o resto da aplicação (um irmão do tronco, ramos, etc ...). Eles têm seu próprio lugar na árvore SVN e são puxados na cada ramo como um Subversion definição externa .

Nós fazê-lo desta maneira, porque cada ramo pode ter muitos servidores implantados a partir dele (dev, teste, construção, automação, etc).