Volant quelque peu de la réponse d' Ian Margett car l'architecture est courante dans la plupart des organisations de développement Microsoft / .NET, le modèle d'exploitation cible de haut niveau ressemble à ceci:
L'objectif est de créer un pipeline de déploiement continu, en utilisant les logiciels existants, à savoir TeamCity , ProGet , SonarQube et Octopus Deploy :
- GitHub est l'outil de gestion du code source, cependant, il peut s'agir de BitBucket ou de Visual Studio Team Services. Le modèle de branchement et le processus de révision du code sont hors de portée à ce niveau élevé.
- TeamCity est choisi comme système de construction en raison de son intégration étroite avec Octopus Deploy et de la bonne prise en charge globale de .NET, msbuild et PowerShell. TeamCity est également utilisé comme orchestrateur de déploiements dans Octopus Deploy.
- ProGet est la solution de gestion de packages qui stocke à la fois les packages Octopus et les référentiels publics de packages / images. La raison de ne pas utiliser le magasin TeamCity NuGet intégré est uniquement pour des raisons d'évolutivité.
- SonarQube fournit une gestion continue de la qualité du code et les rapports sont publiés dans le cadre des sorties de build TeamCity.
- Octopus Deploy est utilisé comme outil de déploiement pour l'infrastructure et le code dans les plates-formes cibles.
J'ai vu cette approche globale mise en œuvre dans deux sociétés et l'ai mise en œuvre avec succès dans deux autres sociétés - dans le cas le plus récent, nous avons échangé TeamCity contre AppVeyor qui a fonctionné, bien qu'un peu pénible lors de la configuration des règles de pare-feu.