Gerenciando configurações de liberação ao usar o TFS Build

5

A organização para a qual trabalho atualmente usa a implantação da Web para ser lançada em diferentes ambientes. A configuração de aplicativos da Web (cadeias de conexão, url de serviço e assim por diante) é gerenciada usando configurações de solução, com as transformações app.config associadas. Com depuração, três ambientes de teste e produção, existem cinco configurações de solução (quatro transformações). Ao implantar em um ambiente, o web deploy cria as soluções com base na configuração selecionada e, em seguida, implanta-a usando a transformação apropriada.

Estou tentando nos levar a usar um processo de gerenciamento de versões e versões mais sofisticado. A empresa está strongmente comprometida com o uso de ferramentas da Microsoft e concordou em usar o TFS Build 2015 (no local).

O processo atual parece-me inadequado para uso em conjunto com uma abordagem de CI / CD e gerenciamento de versão do TFS. Não estou convencido de que uma compilação testada em uma configuração de solução deva ser recriada e promovida em uma configuração de solução diferente. A outra preocupação é que isso seria pesado para a manutenção, exigindo definições de construção separadas e, portanto, definições de versão para cada ambiente.

Eu imagino que apenas duas configurações de solução devam ser usadas (depuração e liberação). O check-in para o ramo de desenvolvimento acionaria automaticamente uma construção de CI usando a configuração de depuração. Para começar, a implantação exigiria uma compilação manual no modo de liberação. A Definição de Liberação pode então ser usada para promover essa construção para cada ambiente com a configuração de aplicativo relevante, conforme necessário.

Eventualmente, o objetivo seria automatizar a implantação no primeiro estágio do teste (por exemplo, através de mesclagem em um ramo de lançamento). Também pode ser útil estender para atender a uma terceira configuração de solução que implante em um ambiente para executar testes automatizados.

Minhas perguntas são:

  • Acredito que é preferível não reconstruir para cada ambiente razoável?
  • Essa é uma abordagem adequada para alcançar meus objetivos ou perdi uma abordagem diferente / melhor?
  • Se seguir essa abordagem, é considerado preferível deixar as configurações de solução em vigor (para as transformações app.config), usando apenas debug / release para a compilação e, em seguida, transformando-as como parte da tarefa de liberação? Ou é melhor gerenciar a configuração por meio das variáveis de ambiente de Definição de Liberação (não temos gerenciamento de configuração centralizado)?
por webdevduck 29.11.2016 / 17:59
fonte

1 resposta

0

Acho que você está no caminho certo.

Is my belief that it is preferable not to rebuild for each environment reasonable?

Você está correto. Você deve construir uma vez e implantar os mesmos artefatos em cada ambiente, alterando apenas os dados de configuração.

Is this a suitable approach to achieve my objectives, or have I missed a different/better approach?

O que você descreveu (duas configurações de solução, promover uma compilação com a configuração de aplicativo relevante) é uma boa solução, na minha opinião.

If following this approach, is it considered preferable to leave the solution configurations in place (for the app.config transforms), just using debug/release for the build and then transforming as part of the release job? Or is it better to manage the configuration through the Release Definition environment variables (we do not have centralised configuration management)?

Acho que não há problema em deixar as configurações de depuração e lançamento no lugar. Você pode usar grupos de variáveis ou simplesmente armazenar os arquivos de configuração específicos do ambiente em um local seguro, puxando-os conforme necessário durante as liberações. Use o que for mais fácil para você manter.

    
por 12.10.2018 / 01:29
fonte