Meilleure solution de processus de build pour gérer les versions de build

Question

Je dirige un projet assez complexe avec plusieurs applications indépendantes.Ceux-ci utilisent cependant quelques composants partagés.J'ai donc une arborescence source ressemblant à celle ci-dessous.

• Mon projet
  • Demande A
  • Partagé1
  • Partagé2
  • Demande B
  • Demande C

Toutes les applications disposent de leur propre script MSBuild qui génère le projet et toutes les ressources partagées dont il a besoin.J'exécute également ces builds sur un serveur de build à intégration continue contrôlé par CruiseControl.

Lorsque les applications sont déployées, elles sont déployées sur plusieurs serveurs pour répartir la charge.Cela signifie que c'est extrêmement Il est important de garder une trace de la build/révision déployée sur chacun des différents serveurs (nous devons avoir la version actuelle dans la version DLL, par exemple « 1.0.0.68 »).

Il est tout aussi important de pouvoir recréer une révision/build qui a été construite pour pouvoir revenir en arrière si quelque chose ne fonctionne pas comme prévu (oh oui, cela arrive...).Aujourd'hui, nous utilisons SourceSafe pour le contrôle de source, mais cela pourrait changer si nous pouvions présenter de bonnes raisons pour cela (SS, cela fonctionne bien pour nous donc loin).

Un autre principe que nous essayons de suivre est que seul le code qui a été construit et testé par le serveur d'intégration que nous déployons ensuite.

Solution « CrusieControl Build Étiquettes »

Nous avons eu plusieurs idées pour résoudre le problème ci-dessus.La première consistait à demander au serveur d'intégration continue de créer, de déployer localement le projet et de le tester (il le fait maintenant).Comme vous le savez probablement, une build réussie dans CruiseControl génère une étiquette de build et je suppose que nous pourrions l'utiliser d'une manière ou d'une autre pour définir la version DLL de nos exécutables (donc l'étiquette de build 35 créerait une DLL comme « 1.0.0.35 ») ?L'idée était également d'utiliser cette étiquette de build pour étiqueter le complet arbre source.Ensuite, nous pourrions probablement vérifier avec cette étiquette et recréer la version plus tard.

La raison de l'étiquetage de l'arborescence complète est d'inclure non seulement le code de l'application réel (qui se trouve à un seul endroit dans l'arborescence source) mais également tous les éléments partagés (qui se trouvent à différents endroits dans l'arborescence).Ainsi, une construction réussie de « Application A » étiqueterait l’arborescence entière avec l’étiquette « ApplicationA35 » par exemple.

Il peut cependant y avoir un problème lorsque vous essayez de recréer cette version et de définir la version de la DLL avant le déploiement, car nous n'avons alors plus accès à l'étiquette de version générée par CruiseControl.Si toutes les étiquettes de build CrusieControl étaient uniques pour tous les projets, nous pourrions utiliser uniquement le numéro pour l'étiquetage mais ce n'est pas le cas (les applications A et B pourraient en même temps être sur la build 35), nous devons donc inclure le nom de l'application dans le étiquette.D'où le label SourceSafe « Application35 ». Comment puis-je ensuite recréer la build 34 et définir 1.0.0.34 sur les numéros de version DLL une fois que nous avons construit la build 35 ?

Solution « Numéro de révision »

Quelqu'un m'a dit que Subversion, par exemple, crée un numéro de révision pour l'intégralité de l'arborescence source à chaque enregistrement : est-ce le cas ?SourceSafe a-t-il quelque chose de similaire ? Si cela est correct, l'idée est alors de récupérer ce numéro de révision lors de l'obtention de la dernière version et de l'utiliser sur le serveur CruiseControl.Le numéro de révision peut ensuite être utilisé pour définir le numéro de version de la DLL (par exemple « 1.0.0.5678 »).Je suppose que nous pourrions alors obtenir cette révision spécifique pour Subversion si nécessaire et cela inclurait alors cette application et tous les éléments partagés pour pouvoir recréer une version spécifique du passé. Cela fonctionnerait-il et cela pourrait-il également être réalisé à l'aide de SourceSafe ?

Résumer

Les deux exigences principales sont donc :

1. Être capable de suivre le numéro de build/révision de la build et de la DLL déployée.
2. Être capable de reconstruire une révision/build passée, définir l'ancien numéro de build/révision sur les exécutables de cette build (pour se conformer à l’exigence 1).

Alors, comment résoudriez-vous cela ? Quelle serait votre approche préférée et comment le résoudriez-vous (ou avez-vous une idée totalement différente ?) ?** Je suis ravi de donner des réponses détaillées.**

Question bonus Quelle est la différence entre un numéro de révision et un numéro de build et quand aurait-on vraiment besoin des deux ?

Answer 1

Votre schéma est solide et réalisable dans VSS (même si je vous suggère d'envisager une alternative, VSS est vraiment un produit obsolète).

Pour votre build "CI" - vous feriez le contrôle de version, jetez un oeil à Projet de tâches communautaires MSBuild qui a une tâche "Version".En règle générale, vous aurez un "Version.txt" dans votre arborescence source et la tâche MSBuild incrémentera le numéro "Release" tandis que les développeurs contrôleront les numéros Major.Minor.Release.Revision (c'est ainsi qu'un de mes clients le souhaitait).Vous pouvez utiliser la révision si vous préférez.

Vous auriez alors une tâche "FileUpdate" pour modifier le fichier AssemblyInfo.cs avec cette version, et vos EXE et "DLL" auront la version souhaitée.

Enfin, la tâche VSSLabel étiquetera tous vos fichiers de manière appropriée.

Pour votre build "Rebuild" - vous modifieriez votre "Get" pour obtenir les fichiers de cette étiquette, n'exécuterez évidemment pas la tâche "Version" (car vous SÉLECTIONNEZ une version à construire), puis les tâches FileUpdate utiliseraient ce numéro de version.

Question bonus:

Ce sont tous "comment vous voulez les utiliser" - j'utiliserais le numéro de build pour, eh bien, le numéro de build, c'est ce que j'augmenterais.Si vous utilisez CI, vous aurez de très nombreuses versions - la grande majorité sans intention de déploiement nulle part.

Le majeur et le mineur vont de soi - mais j'ai toujours utilisé la révision pour un indicateur "Hotfix".J'ai l'intention d'avoir une version "1.3" - qui serait en réalité un produit avec, par exemple, la version 1.3.1234.0.En travaillant sur la version 1.4 - je trouve un bug - et j'ai besoin d'un correctif comme 1.3.2400.1.Ensuite, lorsque la version 1.4 sera prête, ce serait disons 1.4.3500.0

Answer 2

J'ai besoin de plus d'espace que pour répondre, car les commentaires le permettent directement...

Merci!Bonne réponse!Quelle serait la différence, quelle serait mieux résoudre cette subversion par exemple? Richard Hallgren (il y a 15 heures)

Les problèmes avec VSS n'ont rien à voir avec cet exemple (bien que la fonctionnalité "Étiquetage", je crois, soit implémentée de manière inefficace...)

Voici quelques-uns des problèmes avec VSS

1) La ramification est fondamentalement impossible 2) le paiement partagé n'est généralement pas utilisé (je connais quelques personnes qui ont réussi) 3) Les performances sont très médiocres - c'est exteraté "bavard" 4) à moins que vous ayez un très petit référentiel - C'est tout à fait peu fiable, au point pour la plupart des magasins, c'est une bombe temporelle.

Pour 4 - le problème est que VSS est implémenté par l'ensemble du référentiel représenté sous forme de "fichiers plats" dans le système de fichiers.Lorsque le référentiel dépasse une certaine taille (je crois 4 Go mais je ne suis pas sûr de ce chiffre), vous avez un risque de "corruption".À mesure que la taille augmente, les risques de corruption augmentent jusqu’à devenir presque une certitude.

Jetez donc un œil à la taille de votre référentiel - et si vous vous lancez dans les gigaoctets - je vous recommande fortement de commencer à planifier le remplacement de VSS.

Quoi qu'il en soit, un google de "VSS Sucks" donne 30 000 clics...Je pense que si vous commencez à utiliser une alternative, vous réaliserez que cela en vaut la peine.

Answer 3

1. Demandez à CC.net d'étiqueter les builds réussis
2. avoir chaque projet de la solution lié à un fichier solutioninfo.cs commun qui contient les attributs d'assembly et de version de fichier (supprimer de chaque projet assemblyinfo.cs)
3. Avant la construction, demandez au régulateur de vitesse d'exécuter un remplacement d'expression régulière msbuild (à partir des tâches de la communauté msbuild) pour mettre à jour les informations de version à l'aide de l'étiquette de construction cc.net (transmise en tant que paramètre à la tâche msbuild)
4. construire la solution, exécuter des tests, fx cop, etc.
5. Eventuellement, rétablissez le fichier d'informations sur la solution

Le résultat est que tous les assemblys de la version publiée par cc.net ont les mêmes numéros de version qui sont conformes à une étiquette dans le référentiel de code source.

Answer 4

UppercuT peut faire tout cela avec une tâche de packaging personnalisée pour diviser les applications.Et pour obtenir le numéro de version de la source, vous pourriez penser à Subversion.

C'est aussi incroyablement facile de démarrer.

http://code.google.com/p/uppercut/

Quelques bonnes explications ici : Uppercut