Qu'est-ce qui se divise en différents travaux lorsque des fichiers créés dans le travail A sont nécessaires dans le travail B? (Exemple est la construction d'une application .NET en utilisant MSBuild)

Question

Je pense à la meilleure façon de structurer des emplois dans Hudson, et de diviser en emplois. Je vais utiliser une application .NET comme exemple car c'est ce sur quoi je travaille actuellement, mais je pense que beaucoup d'idées sont génériques.

Ce sont les étapes que je veux faire, sans penser à choses se divisant en emplois mais toujours penser à ce que les dépendances sont: (J'espère que vous comprenez ma notation, < - signifie dépend et [X] = AAAAA signifie que AAAAA est une description de la tâche [X].)

• [C] = Consultez le projet, en utilisant Mercurial dans ce cas.
• [C] < - [S] = Exécutez StyleCop sur les fichiers source pour vous assurer qu'ils sont conformes à avec notre norme de codage.
• [C] < - [D] = Créer une documentation à partir de notre projet en utilisant DoxyGen ou Sandcastle.
• [C] < - [O] = Exécutez le plugin de tâches de code pour obtenir une belle présentation de nos commentaires TODO etc.
• [C] < - [B] = Construire la solution en utilisant MSBuild avec la cible Release. Le résultat dans ce cas sera fichiers de bibliothèque compilés à DLL assembler fichiers. Nous aimerions archiver ces artefacts.
• [B] < - [T] = Exécuter des tests NUnit sur les fichiers de bibliothèque.
• [B] < - [F] = Utilisez FxCop pour obtenir une bonne analyse de code statique à partir des fichiers de bibliothèque .
• [B] < - [W] = Utilisez le plugin d'avertissement du compilateur du journal de construction pour pour extraire tous les avertissements donnés lors de la compilation.
• [D], [B] < - [R] = Libérer, créer une archive de version et la télécharger sur un serveur.

Si je partage tous ces en différents emplois:

• Comment dois-je obtenir le code source vérifié que je suis arrivé à l'étape [C] à l'étape [S], [D] , [O], [B] qui ont tous besoin du code source?
• Comment dois-je obtenir le fichier journal MSBuild à l'étape [W] qui était généré à l'étape [B]?
• Comment puis-je obtenir les artefacts DLL générés générés à l'étape [B] dans étape étape [T] et [F] qui en a besoin tous les deux?

Mon principal problème si je partage toutes les étapes en différents projets est comment obtenir ces choses, ces fichiers, entre les différents projets d'une manière agréable (je pouvais de tourner bien sûr des chemins de fichiers de codage dur mais cela semble inflexible, mais je peux me tromper).D'un autre côté, si je les divise en différents projets, j'obtiens moins de complexité pour chaque projet que si je remplissais toutes ces étapes en un seul projet. Il pourrait être difficile à maintenir si j'ai beaucoup de choses dans un projet. Et je ne pourrais pas non plus exécuter des projets disjoints en parallèle, ce qui accélérerait l'ensemble du processus .

Answer 1

J'ai une compréhension différente du 'travail'. Dans mon cas, j'utilise Hudson pour construire plusieurs projets, pour certains projets, j'ai plus d'un travail, mais pas pour les mêmes raisons que celles décrites ci-dessus.

J'utilise un outil de création de projet comme Ant ou Maven pour faire quelques étapes très spécifiques de ma construction comme vos tâches [O] ou [D] par exemple. Pour les étapes plus génériques, j'utilise des plugins hudson qui gèrent ces processus, comme exécuter des tests unitaires, déployer des artefacts.

Je pense que vous trouverez beaucoup de ces plugins à la langue croisée.

Cependant, Hudson est un outil puissant et puissant pour une intégration continue, je peux dire que ce sont les choses difficiles que Maven et ses plugins font. Les rapports de couverture de code, les rapports findbugs, la génération de site de projet, la génération de javadoc, l'instrumentation de code d'octet sont quelques-unes des tâches que je compte faire sur Maven. Donc, j'utilise des tâches différentes quand je veux un objectif final différent pour chaque construction, pas pour faire une chaîne d'éléments que je veux être l'ensemble final d'artefacts. Par exemple, j'ai un travail pour construire mon application toutes les heures et créer des rapports de courrier électronique en cas d'erreurs, et j'ai un deuxième travail pour le même projet qui génère une version de ce projet, celle-ci est appelée manuellement et je l'utilise pour générer tous les documents, rapports et artefacts que je dois assembler afin d'avoir une version stable de mon projet. J'espère que mon avis sur l'utilisation d'Hudson aide.

Answer 2

Vous énumérez quelques tâches pour votre travail. Cela n'a généralement pas de sens d'avoir un travail pour chaque tâche. Il est plus logique de les regrouper. Par exemple, selon mon expérience, il ne vous achète rien d'avoir un travail séparé pour la caisse. Rappelez-vous, plus de travaux rendent un processus de construction plus fragile et rendent leur maintien plus difficile et plus complexe. Commencez par définir vos objectifs/stratégies, puis divisez le processus de construction en tâches individuelles.

La philosophie que je poursuis est de fréquents checkins au dépôt ainsi que chaque checkin ne devrait pas casser la construction. Cela signifie que je dois m'assurer que le développeur obtienne un retour rapide après un checkin. J'ai donc besoin d'un travail C, B, T, W et S dans cet ordre. Si vous préférez, vous pouvez également exécuter O et F avec ce travail. Qu'est-ce que cette commande vous achète. Vous obtenez un retour rapide sur votre élément le plus important, a compilé le code. Le deuxième élément le plus important est, si les tests unitaires font ce qu'ils sont censés faire (tests unitaires). Ensuite, vous testez par rapport aux éléments les moins importants (avertissements du compilateur et normes de codage). Après cela, vous pouvez exécuter vos statistiques. Personnellement, je voudrais exécuter O (ToDos) et F (analyse de code) dans la construction nocturne qui exécute une version complète. Mais vous pouvez également exécuter la version complète à chaque vérification.

Je ne ferais que séparer le processus de construction/édition en étapes plus petites si les artefacts sont nécessaires plus rapidement. Pour moi, il est généralement acceptable lorsque le travail dure jusqu'à 15 minutes. Pourquoi? Parce que je reçois un retour rapide s'il se casse (cela peut être inférieur à 2 minutes), puisque le travail s'arrête ici et ne lance pas les autres tâches (maintenant inutiles). Parfois, je cours des travaux parallèles.Pour l'exécution parallèle et lors de la division d'un travail, j'ai principalement utilisé les dépendances standard ("jobs to build after ...") jusqu'à présent, pour déclencher des projets dépendants, mais surtout j'utilise le parametrized trigger plugin. De plus en plus, j'utilise également le join plugin pour exécuter certaines étapes en parallèle mais ne peut continuer que si les deux parties sont terminées.

Pour passer des fichiers entre deux travaux, j'avais l'habitude d'utiliser un référentiel externe (juste un répertoire partagé sous Windows) et de passer le chemin d'accès aux fichiers en tant que paramètre pour le travail suivant. J'ai changé le comportement et j'utilise maintenant la fonction d'artefacts d'archives d'Hudson et passe l'URL d'exécution du travail au travail suivant, pour les télécharger via HTTP. Cela supprime les problèmes techniques de montage des partages Windows sur Unix (même si CIFS fait un très bon travail). En outre, vous pouvez utiliser le plugin Clone Workspace SCM, ce qui aide si vous avez besoin de l'espace de travail entier dans d'autres travaux.