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)...

[rseM2]

Bonjour Grégory,

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.

Pour pouvoir prendre en compte les projets C, C++ et Ada, je pense que tu passes par le shell pour lancer le build (compilation, tests...). Est-ce bien le cas ?

Si oui, est-ce que tu as des différences (dans les informations de retours, les rapports, la facilité de définir le projet...) par rapport aux projets java qui sont pris en compte (build avec ant et maven...) dans les serveurs d'intégration continue comme Hudson, Continuum ou CC ?

Rémy

[_vince_]

Merci pour cette longue réponse. Finalement, ça a l'air intéressant tout ça...

J'ai oublié de parler de l''installateur sur Windows et du bug tracker. En gros, on utilise InstallShield pour installer les nouvelles versions du logiciel sur Windows. Et on utilise un bug-tracker "maison" qui gère les anomalies mais aussi les campagnes de tests, avec les fiches de tests.

Mon but est d'automatiser les tâches de build et d'installation et aussi d'avoir des outils les plus intégrés entre eux pour faciliter le travail d'intégration/validation.

Mon rêve serait que :
- le développeur puisse faire son commit avec un "commit message" avec le numéro de l'anomalie mis à jour automatiquement dans le bug-tracker (du genre SVN/Trac ou CVS/Bugzilla)
- Avoir un outil d'IC qui fasse le nightly build et qui écrive automatiquement le changelog avec les bugs corrigés. Il faudrait aussi que les bugs aient un état "résolu" quand les corrections ne sont pas encore dans la dernière version compilée. Et un état "livré" lorsque les corrections sont effectivement prises en compte dans la version compilée.
- Et que l'outil d'IC lance l'installation (du InstallShield) et ensuite le déploiement sur les machines cibles.
- Il faudrait pouvoir aussi que le bug-tracker sache aussi gérer une campagne de tests. L'avantage est que si est une fiche de test est NOK, on puisse créér un rapport d'anomalie dans le bug-tracker et que les états des bugs et des tests soient mis à jour automatiquement en fonction des corrections.
- Le nec plus ultra serait que le bug-tracker gère aussi les exigences.

Mes contraintes sont: Visual C++ et ClearCase.

Je ne sais pas si c'est clair. Mais le but est de faciliter le plus possible de le travail d'intégration/validation/qualification/etc grâce à des outils qui font papa maman. Je ne demande pas qu'il fasse le café.

Je suis ouvert à toute bonne idée.

[gboissinot]

Concernant le lancement de build C/C++, cela dépend du type de builder que tu utilises.
Dans le cas ou le builder est un makefile, il faut effectivement mettre en place un mécanisme de détéction du build "failed".Dans CruiseControl, on peut avoir l'attribut errorstr="failed" de la commande exec.
A noter que dans une perspective de centralisation, on peut envisager d'utiliser Maven pour builder du C et C++. Certes avec des contraintes, néansmoins, cela peut convenir dans certains cas, plus particulièrement pour les projets utilisant des librairies dynamiques, se rapprochant de la philipohie bibliothèque jar et repository.

Concernant la traçabilité des builds avec une base d'anomalie et une base d'exigence, le sujet est vaste.
Il n'y a pas de solution unique, cela dépend du besoin et des outils utilisés.

Par exemple, dans le cas de la problématique de liaison du résultat d'un test avec une exigence, comment cette liaison va se réaliser?
Il faudrait produire en sortie le triplet (id du test, id de l'exigence, resultat du test), l'injection dans la base d'exigence et le reporting ensuite.
Mais comment tu va exprimer le lien entre ton test et ton exigence.
Devant le nombre de métriques de tests différentes et de langages différents; pour ma part, j'envisage de partir sur une base de donnée externe de liaison des exigences aux tests. Chaque test et chaque exigence sera un artifact de donnée avec des liens entre eux.

[rseM2]

Bonjour,

- le développeur puisse faire son commit avec un "commit message" avec le numéro de l'anomalie mis à jour automatiquement dans le bug-tracker (du genre SVN/Trac ou CVS/Bugzilla)
- Avoir un outil d'IC qui fasse le nightly build et qui écrive automatiquement le changelog avec les bugs corrigés. Il faudrait aussi que les bugs aient un état "résolu" quand les corrections ne sont pas encore dans la dernière version compilée. Et un état "livré" lorsque les corrections sont effectivement prises en compte dans la version compilée.

Pour information, nous avons réalisé un plugin maven scmchangelog-maven-plugin qui permet à partir des messages de commit dans le SCM de générer automatiquement le changelog dans un rapport maven 2. Les messages de commit doivent juste suivre une certaine grammaire où il est possible d'indiquer les numéros d'issue. Dans le rapport, un hyperlien sur le numéro d'issue est ajouté pour pouvoir le retrouver sur le bug tracker (jira et codex pour le moment) .

Pour le moment ce plugin est dans le sandbox de codehaus mais on va essayer de faire une première release prochainement pour qu'il soit directement dans la liste des mojos.

Rémy

[_vince_]

Par exemple, dans le cas de la problématique de liaison du résultat d'un test avec une exigence, comment cette liaison va se réaliser?
Il faudrait produire en sortie le triplet (id du test, id de l'exigence, resultat du test), l'injection dans la base d'exigence et le reporting ensuite.
Mais comment tu va exprimer le lien entre ton test et ton exigence.
Devant le nombre de métriques de tests différentes et de langages différents; pour ma part, j'envisage de partir sur une base de donnée externe de liaison des exigences aux tests. Chaque test et chaque exigence sera un artifact de donnée avec des liens entre eux.

On utilise un outil "maison" qui gère des campagnes de test, avec les fiches de tests, les résultats de tests. Et on peut relier une fiche de test à une exigence.
Donc on a le triplet dont tu parles.

En ce moment, j'essaie de voir l'état de l'art des outils de validation pour nous faciliter la tâche. Et je cherche des outils qui concentrent le plus de fonctions possibles pour éviter d'avoir une multitude d'outils hétérogènes où le partage d'informations est impossible. L'idée est aussi d'utiliser des outils "mainstream" et non "maison".

[ehsavoie]

Il faut lire sourceforge et non codex dans la remarque de Rémy ;o).
Notre release a été un peu retardée car nous attendions maven-scm-plugin 1.1 et l'API a légèrement évolué par rapport à la version pour laquelle le plugin avait été écrit.