Déploiement d'un système .net distribué avec plusieurs solutions

Question

Nous avons un système .net distribué qui consiste en plusieurs solutions, chacune avec des besoins de configuration et de déploiement différents. Actuellement, tout le code est dans un projet TFS et chaque solution a sa propre construction. Ceux-ci sont configurés pour déclencher des modifications dans ce dossier de contrôle de source de solutions. Nous passons à Team City, Git and rake (en raison de la facilité des branchements et des coûts de licence) et nous examinons donc l'ensemble du processus de construction et n'avons pas été en mesure de trouver de bonnes informations à ce sujet. Les problèmes que nous avons du mal à résoudre sont les suivants:

1. Devrions-nous avoir des versions séparées ou une grande construction? Toutes les solutions doivent être construites et déployées pour que le système fonctionne, mais il est agréable d'avoir de petites versions car elles sont rapides et faciles à déboguer. Certaines solutions sont plus «autonomes» que d'autres. Notre pratique actuelle consiste principalement à mettre en file d'attente toutes les versions lorsque nous voulons les déployer dans un environnement de test ou de production, mais parfois, nous mettons simplement en file d'attente une solution individuelle si c'est tout ce qui a changé.

2. Faut-il stocker toutes les solutions dans un référentiel ou devrions-nous avoir un référentiel pour chacune d'elles? Nous utilisons des projets partagés et des DLL, comment cela fonctionnerait-il avec des dépôts séparés?

Answer 1

Il existe de nombreuses façons de stocker des référentiels, de réaliser des builds et de déployer des instances. Et beaucoup d'entre eux ont raison. De ma pratique, il n'est pas important quelle technique vous utilisez et quel outil pour faire les builds et le déploiement. Il est donc important de soulever des questions qui affectent ces processus:

• pour éviter le déconcentration des solutions/projets qui peuvent être séparés (en mode autonome). Si un projet est partagé entre plusieurs solutions, il est préférable de créer un référentiel distinct pour ce dernier. Et ajoutez simplement des relations de solutions/projets dépendants à ceci;
• pour éviter les problèmes lors de la génération de différentes générations à des fins différentes (gestion de la configuration en d'autres termes). Vous pouvez ajuster TeamCity pour ceci (principalement pour l'automatisation de construction et de déploiement après chaque 'commit' ou horaire programmé), ou utiliser un utilitaire simple mais puissant comme NAnt avec des configurations prédéfinies.

Je ne vois aucune raison de faire une grande accumulation (uniquement sur la libération peut être), mais séparés construit serait plus facile à utiliser (pour l'AQ et les développeurs qui travaillent sur une partie seulement). Le deuxième problème est un moment. Par exemple, pour créer une version complète avec tous les projets en une seule solution, il faut environ 10 minutes sur le quad cpu 8gb ram, mais pour faire une compilation avec la partie Accounting ou Inscription, cela prend seulement une minute - ça compte pour moi. Essayez simplement d'imaginer ce processus, dessinez sur un morceau de papier, et il devient clair - que faire, et pourquoi le faire. Toutes les opinions sont basées sur ma pratique seulement, dans des projets réussis qui connaissent des changements chaque jour/nuit et qui ont des dizaines de configurations (vos builds).