De certa forma, roubar a resposta de Ian Margett, como a arquitetura é comum entre a maioria das organizações de desenvolvimento Microsoft / .NET, o modelo operacional de alto nível para algo parecido com isto:
O objetivo é criar um pipeline de Implantação Contínua, usando software de prateleira existente, como TeamCity , ProGet , SonarQube e Octopus Deploy :
- O GitHub é a ferramenta de gerenciamento de código-fonte, no entanto, pode ser o BitBucket ou o Visual Studio Team Services. O modelo de ramificação e o processo de revisão de código estão fora do escopo nesse nível alto.
- O TeamCity é escolhido como o sistema de compilação devido à sua forte integração com o Octopus Deploy e ao bom suporte geral para .NET, msbuild e PowerShell. O TeamCity também é usado como orquestrador de implantações no Octopus Deploy.
- O ProGet é a solução de gerenciamento de pacotes que armazena Octopus Packages e proxies repositórios públicos de pacotes / imagens. A lógica para não usar a loja TeamCity NuGet incorporada é puramente por motivos de escalabilidade.
- O SonarQube fornece gerenciamento contínuo da qualidade do código e os relatórios são publicados como parte das saídas de construção do TeamCity.
- O Octopus Deploy é usado como a ferramenta de implantação da infraestrutura e do código nas plataformas de destino.
Eu vi essa abordagem ampla implementada em duas empresas e implementada com sucesso em duas empresas adicionais - no caso mais recente, trocamos o TeamCity pelo AppVeyor, que funcionou, embora um pouco doloroso ao configurar regras de firewall.
