Discussion :

[_vince_]

Bonsoir,

Ma question ne concerne pas les outils mais le process d'IC.

Dans mon nouveau boulot, on applique une sorte d'intégration continue où les codeurs codent, on produit une nouvelle version toute les nuits, et les testeurs testent le lendemain, rédigent des rapports d'anomalie.

Ce qui me choque, c'est qu'il n'y pas d'identificateur unique de version (ou de build). Les rapports d'anomalie mentionnent le numéro de version en cours de développement, mais pas le numéro de build, ou une date de build. Il est donc impossible de différencier la version de la veille, de celle du jour courant, de celle du lendemain, etc.

Ma question est donc la suivante: Est-ce que vous utilisez un numéro de build qui s'incrémente chaque nuit (pour la version en cours de développement) ? où à chaque build ? Comment ça se passe pour vos projets ?

Merci pour vos réponses

[romaintaz]

Bonjour,

Sur un ancien projet, nous utilisions Cruise Control.
Il y avait la possibilité, dans le pom.xml de Maven de notre projet, d'inclure le numéro du build de l'IC. Je parle bien du numéro du build, pas de la version du projet.
Hélas, je n'ai plus en tête la méthode que nous utilisions...

En faisant une petite recherche sur le web, j'ai trouvé cette page très intéressante sur Hudson (si c'est l'outil d'IC que tu utilises).
Le principe : Hudson, lorsqu'il lance un build, définit un certain nombre de variables d'environnement, comme BUILD_NUMBER (c'est ce qui t'intéresse), BUILD_ID, JOB_NAME, etc.
L'idée est donc d'utiliser, dans ton pom.xml (ou dans une ressource filtrée par Maven), ce BUILD_NUMBER.
Sur la page donnée, on explique comment ajouter des informations dans le Manifest. Mais rien ne t'empêche d'utiliser ces variables ailleurs, comme pour afficher la version et le build number sur la page d'accueil de ton application...

Mon explication est-elle suffisante ?

[_vince_]

En fait, on n'utilise pas d'outil du commerce, mais de simples tâches planifiées qui activent des scripts "maison". Ces scripts lancent la compilation sous Visual C++. C'est un peu l'usine à gaz mais on devrait pouvoir ajouter un numéro de build et une date de build.

Merci pour les infos. En fait, je voulais juste avoir la confirmation que générer un numéro de build fait partie des bonnes pratiques. Les personnes avec lesquelles je travaille ne l'ont pas fait, ça me choquait un peu... voilà. C'est tout pour le moment.

[gboissinot]

Bonjour,
Dans le cas de nightly build, il est crucial de mettre en place un mécanisme de trace.
Utiliser un numéro de build n’est utile que s’il existe un mécanisme de liaison avec d’autres outils externes. Sinon, l’information est peu pertinente.
C’est pourquoi je recommanderais le timestamp du build.
Plus précisément, dans ton cas, tu peux renommer les binaires produits en suffixant du timestamp du build pour un meilleur suivit.

En revanche, je te conseille vivement une migration vers un scheduler, en particulier sur Hudson.
Un premier niveau de migration qui consisterait a lancer les scripts existent est presque gratuite.
Une automatisation des tests dans un second temps viendrait enrichir le processus.

[_vince_]

En plus un timestamp est beaucoup plus parlant qu'un numéro.

Pour ce qui est d'utiliser un outil d'IC, je suis pour. Mais l'utiliser en tant que simple scheduler, je n'en vois pas l'intérêt. Ce serait dépenser de l'énergie à migrer pour avoir la même fonctionnalité.

D'après le peu que j'ai lu sur les outils d'IC, il me semble que ces outils sont très orientés pour des projets Java sur des plate-formes Unix/Linux.

Pour mon cas perso, le projet compile avec Visual C++ sous Windows XP. Le SCM est Clearcase. Y a-t-il des forumeurs qui utilisent des outils open source d'IC avec ces contraintes là ? Et si oui, j'aimerais bien avoir leur retour d'expérience sur l'installation et les bénéfices de ces outils sur des cas réels. Et je suis preneur de toute bonne idée ;-)

Bonne soirée

[gboissinot]

La majorité des outils d'intégrations continue sont certes des outils développés en Java.
Néanmoins, cela ne suffit pas qu'ils ne permettent que de scheduler des programmes Java.

Chez mon client, je travaille sur l'intégration continue pour des projets C,C++,Ada et Java.
Les deux outils d'intégration continue utilisés sont CruiseControl et Hudson.
Je gère deux types de SCM : Clearcase, plus précisément ClearCase UCM; ainsi que Subversion.
Les plateforme de build sont Windows et Linux.

Les avantages de l'utilisation de tels outil sont l'outillage apporté:
-Flexibilité pour la mise en œuvre d'une orchestration d'une chaine de build
-Flexibilité de communication avec un SCM
-Configuration et paramétrages des scripts à lancer
-Post actions gratuites (re-nommage des artifacts, envoie de mail, reporting de métriques)
-Mécanisme de traçabilité des changement du code source avec les personnes qui ont fait le commit entre deux build, ...
-Reporting de l'exécution de chaque build
-Mécanisme d'historisation des builds
-Tu peux paralléliser les builds
-Tu va pouvoir créer des configuration de builds par environement
-...

Dans ton cas avec ClearCase, tu vas pouvoir utiliser trois modes de fonctionnement qui sont non exclusif :
-Écoute des modification sur une vue Clearcase à intervalle régulier. Le build se déclenchera uniquement en cas de modification
-Build périodique, qu'il y ait ou pas de modification en gestion de configuration
-Déclenchement du build au moment du deliver Clearcase, par exemple d'un stream de développement à un stream d'intégration, grace à un mécansisme de trigger qui déclenche le build

CruiseControl offre une très grande flexibilité de dialogue avec ClearCase et Clearcase UCM.
Hudson en revanche est pour le moment limité dans l'utilisation de ClearCase UCM.
Néanmoins, je conseille d'utiliser Hudson en mode Clearcase de base avec l'édition d'un config spec permettant donc de tout faire.

Malgré cette intégration ClearCase qui n'est pas encore très mature dans Hudson, cet outil propose de très nombreuses fonctionnalités que ne propose pas les autres produits. Son mécanisme de plugin en fait un outil très extensible. Sa très grande richesse de la bibliothèque de plugin en fait un outil incontournable.

Installation des outils:
Je privilégierais une installation Web application consistant à déployer ton moteur d'intégration continue packagé en war dans un container Web comme Tomcat.

--
Grégory

[romaintaz]

Pour mon cas perso, le projet compile avec Visual C++ sous Windows XP. Le SCM est Clearcase. Y a-t-il des forumeurs qui utilisent des outils open source d'IC avec ces contraintes là ?

Hudson ne propose de base que la gestion de CVS et SVN. Toutefois, il existe plusieurs plugins pour gérer d'autres SCM, dont ClearCase.
Quant à intégrer des projets C++ ou .Net dans Hudson, c'est également possible (mais je ne l'ai pas fait personnellement)...