Communiqués automatisés avec Hudson + Ant + Subversion

Question

Nous avons récemment développé Hudson pour une intégration continue, et nous commençons à profiter des avantages du test automatisé, de l'analyse statique, etc. Notre prochaine étape consiste à lancer notre processus de relâchement manuel encombrant. Ce que j'imagine est un processus en deux phases:

1. Branche pour une ligne de libération. Une fois que notre ligne de développement se sera stabilisée, nous aimerions nous lancer. Parce que nous avons des utilisateurs à faible densité et à forte demande, il y a souvent un peu d'activité à la suite d'une sortie officielle, ce qui entraîne un peu de stop-and-go-développement au début d'une ligne de lancement (et nous ne vouloir bloquer le développement de la ligne principale pour cela), donc la pratique de se ramifier à un moment opportun, puis de permettre une fenêtre de stabilisation (des heures à un jour ou deux) est logique. (Ceci est fait dans subversion, habituellement nous marquons la version de développement immédiatement avant la branche, puis nous branchons, puis nous poursuivons le développement parallèle)

2. Couper une version de la branche. Cela implique actuellement

   1. Un peu de "correction" pour mettre les numéros de version où ils appartiennent.
   2. Checkin
   3. Tag
   4. Export
   5. Construire
   6. Un peu de "fixup" pour revenir numéros de version à "devel/instantané".
   7. Checkin

Donc, pour opérationnaliser quelque chose comme ça à Hudson, proprement, comment pouvons-nous:

• exécuter une opération de branche d'Hudson que les branches de l'arbre, étant donné une nouvelle version nom de la branche et génère un nouveau travail Hudson pour créer une nouvelle ligne de construction continue pour cette branche. (Il est proche d'une copie de la configuration -trunk existante, mais doit remplacer certains noms d'espace de travail et des choses ...)

• D'où vient la logique d'interagir avec Subversion? (Peut-être pourrait être dans le script ant, pourrait être un script séparé, Hudson/plugins semblent également fournir une partie de cette logique?)

• Toute réflexion sur les utilisateurs/autorisations pour Hudson/processus subsidiaires quand il parle à la repo en mode écriture? En ce qui concerne la phase deux, les questions ci-dessus s'appliquent également. Puis-je utiliser le plugin release pour automatiser une logique comme celle-ci?

J'ai lu attentivement la documentation Plugin Hudson et la libération, mais il est plutôt inégale et il n'y a pas beaucoup d'exemples de travail disposés de bout en bout ...

Edité pour ajouter : Je comprends et attendais le "Avez-vous considéré Maven?" réponses ... J'apprécie, et je comprends que Maven est probablement la bonne solution à long terme, mais un changement de système de construction avec toute la force et le drang de passer aux contraintes précises de Maven et d'éduquer le personnel technique n'est pas réalisable À court terme. Vraisemblablement, il y a un moyen de le faire avec Ant et une petite graisse de coude ...

Answer 1

à court terme processus basé sur Ant

Compte tenu de votre engagement envers le processus de construction Ant (et il n'y a rien de mal à cela, sauf pour les goodies que vous êtes absent sur) Je vous suggère que vous mettez en miroir le Maven approche, mais le faire dans Ant. Donc, ayez une complète read of this article that shows how to use SVNAnt.

Solution idéale pour le long terme

Comme @Peter Lawray a mentionné, Maven est votre ami ici. Examinez spécifiquement le plugin de publication qui gérera le processus de marquage de votre référentiel Subversion avec la version "gold release" de votre projet. Essentiellement, vous effectuez une construction complète (y compris des tests fonctionnels si vous les avez) pour vérifier votre artefact, puis Maven balise votre repo Subversion et enfin il court sur vos fichiers pom.xml de projet et les re-versions au niveau suivant en haut (comme des instantanés). En termes de processus de construction, Hudson travaille joyeusement avec Maven et construit et teste les artefacts (vos fichiers JAR, WAR, EAR, etc.) dans la séquence que vous spécifiez dans le fichier pom.xml de Maven.

Vous pouvez lier SeleniumRC et fournir un environnement de test fonctionnel automatisé multi-navigateur si vous le souhaitez. Maven gère tout depuis la construction, jusqu'au déploiement de l'artefact dans le serveur de construction, puis les tests fonctionnels ultérieurs avec une dernière validation par un processus de libération. Je suis blogged a little about this si vous êtes intéressé.

Answer 2

Ceci est conçu comme une solution jusqu'à ce que vous ayez maven en place.

Je pense que vous devriez simplement créer des scripts pour faire tout le travail (soit des scripts ant et/ou batch/shell). Jetez un oeil à la Batch Task plugin. Cela vous permet d'exécuter la version sur l'espace de travail actuel de votre travail. Votre script (s) sont destinés à faire tout le travail. Vous pouvez créer une copie de votre travail en cours en utilisant le remote api. Si les variables d'environnement, comme JobName, ne sont pas disponibles, vous devrez probablement coder en dur le nom du travail (ou les enregistrer pendant la construction dans un fichier sur l'espace de travail). A la fin, vous aurez un tronc mis à jour (ligne de dev), une nouvelle ligne de sortie (dans les branches) et un travail qui exécute tout votre CI sur la branche de publication.

Answer 3

Je ne ferais pas le branchement et le marquage dans le cadre de la construction, je le ferais à la main. C'est (encore!) Peut-être une différence philosophique: je vois Hudson comme un moyen de prendre l'état actuel d'une ligne de code et de produire ses artefacts, plutôt que comme un outil pour manipuler les lignes de code. C'est comme un gros compilateur, mais pas comme un IDE.

Alors, mon processus ressemblerait (et notre processus, en fait, ne ressemble):

1. Tag au point de sortie (appeler root_release23_20101124)
2. Direction générale à ce moment-là (appeler release23_20101124)
3. Modifier les propriétés de libération des fichiers à ajouter le numéro de version, et ce que d'autres fixup
4. Arrivée à la branche
5. Mettre en place un nouvel emploi Hudson (en copiant un travail de modèle) pour construire un rel la facilité, le configurer pour vérifier de la branche
6. exécuter le travail

Ainsi, la mise en place d'une nouvelle version est un développeur/build tâches manager, mais en fait la construction de la libération se fait par Hudson.

La création d'une version implique un travail manuel, mais vous ne pouvez pas l'appeler fastidieux - combien de temps faut-il pour marquer, brancher, éditer quelques fichiers, valider, créer un travail et changer son nom de branche?