Vous êtes sur la page 1sur 71

Universit de Fribourg, Suisse Dpartement d'informatique Bachelor en informatique de gestion

INTGRATION CONTINUE Concept thorique et dveloppement d'une plate-forme d'intgration automatise pour un projet informatique.

Travail de Bachelor

Auteur: Chatton Marc Rte des Acacias 9 1700 Fribourg

Responsable: Dr Stefan Hsemann

Fribourg, Septembre 2010

Table des matires

Table des matires


1 INTRODUCTION ....................................................................................................... 1 1.1 1.2 1.3 1.4 2 Motivations .................................................................................................... 1 Objectifs ......................................................................................................... 1 Structure du travail ......................................................................................... 3 Conventions ................................................................................................... 3

PRSENTATION GNRALE DU CONCEPT DIC ...................................................... 5 2.1 2.2 2.3 2.4 2.5 Quest-ce que lIC? ........................................................................................ 5 Historique ....................................................................................................... 5 Avantages ....................................................................................................... 6 Dsavantages.................................................................................................. 8 Les difficults de la mise en place ................................................................. 9

3 4

PRSENTATION DES DIFFRENTS ENVIRONNEMENTS DANS LIC. ....................... 11 PRSENTATIONS DES 6 DISPOSITIFS QUI DFINISSENT LIC. ............................... 13 4.1 4.2 Compilation du code-source ........................................................................ 13 Intgration de la base de donnes ................................................................ 13 4.2.1 Local Sandbox .............................................................................. 15 4.2.2 Les bonnes pratiques .......................................................................... 15 4.3 Lancer les tests ............................................................................................. 16 4.3.1 Tests unitaires..................................................................................... 17 4.3.2 Tests dintgration .............................................................................. 17 4.3.3 Tests systme ...................................................................................... 17 4.3.4 Tests fonctionnels (ou dacceptation) ................................................. 18 4.3.5 Defect Driven Development ......................................................... 18

Table des matires 4.4 4.5

Inspection ..................................................................................................... 19 Dploiement ................................................................................................. 22 4.5.1 Etiqueter les donnes du repository ............................................. 23 4.5.2 Produire dans un environnement sain ................................................ 23 4.5.3 Gnrer et tiqueter un build issu du repository .......................... 23 4.5.4 Lancer des tests de tous niveaux dans un clne de lenvironnement de production........................................................... 24 4.5.5 Crer des feedbacks pour le build ...................................................... 24 4.5.6 Possibilit de revenir une version prcdente ................................. 24

4.6

Feedback ...................................................................................................... 24 4.6.1 Les bonnes informations ..................................................................... 25 4.6.2 Les bonnes personnes ......................................................................... 25 4.6.3 Le bon moment ................................................................................... 26 4.6.4 La bonne manire ............................................................................... 26

OUTILS ET AUTOMATISMES ADOPTER POUR UNE IC IDALE ........................... 27 5.1 Rflexes avoir pour le repository .............................................................. 27 5.1.1 Utiliser le repository pour stocker tous les fichiers ........................... 27 5.1.2 La Staging Area ............................................................................. 27 5.2 Rflexes avoir pour le build ...................................................................... 28 5.2.1 Types de build ..................................................................................... 29 5.2.2 Les faons de le lancer ....................................................................... 30 5.2.3 Automatiser le build ........................................................................... 30 5.2.4 Lexcuter via une seule commande ................................................... 30 5.2.5 Crer de plus petites quipes en sparant les tapes de dveloppement .................................................................................... 31 5.2.6 Attribuer un poste de Chef de build .............................................. 31 5.2.7 Sparer le build de lenvironnement de dveloppement IDE ............. 31

Table des matires

5.2.8 Faire en sorte que les builds chouent rapidement ............................ 31 5.2.9 Faire quun build soit compatible peu importe lenvironnement ....... 32 5.2.10 Utiliser une machine ddie pour le build dintgration ............... 32 5.2.11 Lancer des builds rapides .............................................................. 33 5.2.12 Refactorer les builds pour optimiser le processus ......................... 35 6 LES OUTILS DE DVELOPPEMENT ......................................................................... 37 6.1 Le serveur d'IC ............................................................................................. 37 6.1.1 AnthillPro ........................................................................................... 37 6.1.2 CruiseControl .NET ............................................................................ 38 6.2 Les Builds scripts ......................................................................................... 38 6.2.1 (N)Ant ................................................................................................. 38 6.2.2 Maven ................................................................................................. 39 6.3 Le systme de contrle de versionnement ................................................... 39 6.3.1 Subversion .......................................................................................... 39 6.3.2 TortoiseSVN........................................................................................ 40 6.4 Les Feedbacks .............................................................................................. 40 6.4.1 Doxygen .............................................................................................. 41 7 LAVENIR DE LIC ET SES ALTERNATIVES ........................................................... 42 7.1 7.2 8 Avenir de lIC .............................................................................................. 42 Les alternatives ............................................................................................ 45

ENVIRONNEMENTS DE DVELOPPEMENT DE LA BSU .......................................... 47 8.1 8.2 8.3 Situation sans IC .......................................................................................... 47 Situation aprs mise en place de lIC ........................................................... 48 Analyse SWOT ............................................................................................ 50

CONCLUSION ......................................................................................................... 56

Table des matires 10

GLOSSAIRE ET TABLE DABRVIATION ................................................................ 58 10.1 Glossaire ...................................................................................................... 58 10.2 Table dabrviation ...................................................................................... 60

11

BIBLIOGRAPHIE .................................................................................................... 61

Table des matires Graphiques

FIGURE 3-1 : LES COMPOSANTS DUN SYSTME DIC, [DUVALL 2007, P. 5] ............................................... 11 FIGURE 4-1: EXEMPLE DE LUTILISATION DUN LOCAL SANDBOX POUR CHAQUE DVELOPPEUR, [DUVALL 2007, P. 118] ..................................................................................................................................... 15 FIGURE 4-2: LE FEEDBACK COMME PAUL M. DUVALL LE CONOIT, [DUVALL 2007, P. 206] ...................... 25 FIGURE 5-1 : LA STAGING AREA [CROSSROADS 2004] ................................................................................ 28 FIGURE 5-2 : LE BUILD SCRIPT CONFIGUR POUR S'ADAPTER CHAQUE ENVIRONNEMENT, [DUVALL 2007,
P. 79] ................................................................................................................................................

32

FIGURE 5-3 : TABLEAU INDIQUANT LES AMLIORATIONS POSSIBLES ET SES CONSQUENCES (LVOLUTIVIT, LA PERFORMANCE ET LES DIFFICULTS QUI EN RSULTENT), REPRISE DU GRAPHIQUE
DE [DUVALL 2007, P. 90] ...................................................................................................................

35

FIGURE 7-1 : CODAGE-VRIFICATION-COMMIT SELON TEAMCITY [TEAMCITY 2009] .......................... 42 FIGURE 7-2 : COMMIT 2 PHASES, [DUVALL 2007, P. 224] ......................................................................... 43 FIGURE 8-1 : SITUATION DE LENVIRONNEMENT DE DVELOPPEMENT DE LA BSU AVANT LA MISE EN PLACE
DUN SYSTME DIC ..........................................................................................................................

48

FIGURE 8-2 : MISE EN PLACE DE LIC POUR LA BSU .................................................................................. 49 FIGURE 8-3 : CHEMINEMENT DE LANALYSE SWOT [GROUPERESSOURCES.COM 2010] ............................. 50

1 Introduction

1
1.1

Introduction
Motivations

Javais dj quelques ides dorientation pour le travail qui mattendait : travailler avec des bases de donnes, aborder des technologies telles que celles utilises par Bluewin TV (Teleclub) pour la retransmission des vnements sportifs ( achat du match par le tlspectateur depuis son canap) et den faire une tude de march, etc. Cependant, cest suite aux discussions que jai eues avec le Dr. Stefan Hsemann, que jai rencontr via lassociation dtudiants BSU (Brsenspiel der Schweizer Universitten), et dont il est le Prsident du Vorstand (sorte de conseil dadministration des anciens Prsidents du jeu) que jai opt pour une autre voie. Il ma propos de travailler sur lenvironnement de dveloppement du logiciel qui permet de gnrer ce jeu boursier. Cest dailleurs l que jai pris pour la premire fois la connaissance du terme Continuous Integration (Intgration continue). Aprs quelques recherches sur le sujet, jai pu remarquer que le terme tait relativement rcent et que dailleurs, quasiment aucune information ntait disponible en franais. Au fur et mesure de mes recherches, jai aussi pu constater que mme si le terme ntait que peu utilis, il nen restait pas moins indispensable pour chaque entreprise de dveloppement informatique de mettre en place un environnement de dveloppement la hauteur de leurs ambitions. Ce paradoxe (peu dinformations et application du concept quasi-systmatique pour les dveloppeurs) ma intrigu et pouss approfondir le sujet, et mme de lappliquer une dimension raisonnable pour de petits projets informatique dvelopp par la BSU. 1.2 Objectifs

Lobjectif principal est de prsenter les tenants et aboutissants du concept d intgration continue dans un cadre thorique dans un premier temps, puis de lappliquer avec les outils disposition pour un projet informatique de petite envergure. Dcouvrir de nouveaux langages de programmation ainsi que la cration dun environnement de dveloppement viable pour un projet informatique, faisaient de ce travail un dfi trs intressant. En dmarrant ce travail, jai essay de me poser les questions les plus pertinentes et cibles possibles sur le sujet. Cest dailleurs en me basant sur celles-ci que jai

1 Introduction

structur mes chapitres dans lobjectif de pouvoir rpondre toutes ces questions dans un ensemble concis et cohrent.

Partie thorique: Qu'est-ce que l'intgration continue?

Je prsenterai le concept dIC qui sera expos dans sa globalit avant dtre analys en dtail. Quelles sont les composants principaux pour la mise en place?

L'environnement de dveloppement reprsentatif sera prsent l'aide d'un graphique et dvelopp point par point. Quelles tapes pour y parvenir?

Jai relev 6 tapes qui constituent l'IC, savoir : la compilation, lintgration de la base de donnes, les tests, linspection, le dploiement et le processus de feedback . Une partie sera entirement consacre la prsentation de ces diverses tapes. Quelles sont les avantages/dsavantages auxquels on peut s'attendre?

Il sera expliqu tous les avantages que l'IC peut apporter au dveloppement d'un projet, ainsi que les inconvnients inhrents sa mise en place. Quels outils pour l'IC?

Une prsentation non-exhaustive de quelques outils pour le versionnement (repository), pour le serveur d'intgration, pour les tests, pour l'inspection et pour les feedbacks . Que peut-on esprer de plus pour l'IC ?

Le futur de l'IC sera prsent, avec les optimisations qui en dcoulent.

Partie pratique: Quelles sont les apports envisags pour la BSU ?

Il sera expos la situation avant et aprs linstallation de cette plateforme dIC pour cette association. Une analyse SWOT permettra de mieux cerner les avantages et dsavantages qui en dcoulent.

1 Introduction

Comment l'IC peut tre mise en place pour un petit projet informatique utilisant des technologies .NET?

Cette question reprsentera l'essentiel du travail pratique, on y rpondra via la ralisation de l'infrastructure de l'IC pour un projet informatique ralis pour la BSU.. Cette partie sera prsente dans une annexe de ce travail et sera prsente comme un guide pour la mise en place dune IC. 1.3 Structure du travail

Ce travail se compose principalement en 2 parties : une premire thorique puis une seconde pratique. On se concentrera, dans la partie thorique, sur lapprofondissement des outils qui permettent lapplication de lIC proprement parler. Ceci servira de passerelle avant lapplication concrte du concept dans la partie pratique. Cette seconde partie abordera le cas de la BSU, o une plateforme dIC a t dveloppe sur le serveur dintgration de lassociation. Un guide dinstallation et dutilisation sera galement disponible dans une annexe, ce avec certains codes de la partie pratique (il sagit-l des fichiers de configurations des diffrents programmes utiliss, lessentiel du travail tant dans la configuration du serveur). Il ne contient que trs peu dinformations vu que, une fois implment, le serveur dIC nexige que peu de manipulations pour quil soit fonctionnel. Les derniers points se rsument un support o vous seront expliqus les diffrents termes abords ainsi que la bibliographie qui a t utilise tout au long du travail. 1.4 Conventions On donnera la signification dun acronyme entre parenthses, lors de sa premire utilisation. Inversement, lorsquon crera un acronyme pour allger le texte, il sera donn en relation avec sa signification. Les termes anglophones qui nont pas dquivalent en franais seront mis entre crochets ....

1 Introduction

Les notions abordes qui seront (ou taient) dveloppes dans un chapitre ultrieur (resp. prcdent) seront accompagns dun lien en italique vers le chapitre en question (par exemple (cf. Chapitre 5.2.12 pour les dtails)).

LURL (Uniform Ressource Locator) complet dun site Web sera rfrenc dans la partie Bibliographie en fin de document, avec la date de la dernire visite.

Le numro des figures utilises dans le document correspondent leur ordre dapparition dans un chapitre.

Une citation dun auteur se fera en italique et comportera une rfrence son auteur (par exemple [Martin Fowler 2006]).

Une ide (ou concept) voque par un auteur et reprise dans ce travail sera rfrence par un cf. (par exemple cf. [Duvall 2007, p. 111] ).

Les nologismes (par exemple des termes anglais franciss) seront galement placs entre crochets ....

Les parties de code seront mises en italique.

2 Prsentation gnrale du concept dIC

Prsentation gnrale du concept dIC

Avant de se lancer dans une explication plus technique ou dapprofondir larchitecture ncessaire sa mise place, il est important de dfinir la notion dIC, de comprendre pourquoi les programmateurs ont commenc sen servir, ainsi que les avantages et dsavantages qui en dcoulent. Ce chapitre nous offre donc un premier aperu du sujet. 2.1 Quest-ce que lIC? Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. [Fowler 2008] L'intgration continue est une pratique de dveloppement informatique qui consiste devoir intgrer (donc entre autres : compiler, tester et dployer) les changements appliqus sur les lignes de code du programme avant de commencer une nouvelle tche. Le but est de proposer un feedback rapide si un dfaut a t dtect dans le codesource, le problme pouvant tre identifi et corrig dans les plus brefs dlais. Il en rsulte un programme plus stable et dvelopp plus rapidement. L'expression intgration continue est plus une accroche syntaxique qu'une description formelle. On utilise ce terme pour mettre en exergue le fait qu'un build journalier ou hebdomadaire n'est simplement pas suffisant. Le terme continue ( continuous en anglais) est par ailleurs techniquement incorrect puisque cela implique qu'il ne s'arrte jamais dans le temps, que le systme intgre de faon incessante, ce qui est physiquement impossible. Il aurait t plus juste d'utiliser le mot continuelle ( continual ) qui aurait le sens de quelque chose qui se rpte intervalles trs rapprochs. 2.2 Historique

Avant, on pouvait parler de Big Bang Integration , avec ce concept (qu'on peut comparer l'approche Run it and see ) les diffrents modules n'taient pas intgrs avant qu'ils ne soient tous oprationnels. On intgrait ensuite le programme sans vritables tests pralables et on le lanait pour s'assurer de son bon fonctionnement. Les dfauts de cette mthode prouvaient que cette voie n'tait pas satisfaisante: haute

2 Prsentation gnrale du concept dIC

probabilit de dcouvrir des dfauts critiques dans la phase de production, difficults isoler le dfaut (Provient-il de l'interface? Du composant?), etc.

Kirk Knoernschild, auteur d'un article sur l'IC, prsentait le Big Bang Integration comme une mthode qui retarde la dcouverte des erreurs et la rduction du risque ce qui peut avoir des rsultats dsastreux sur l'effort de dveloppement, incluant un appauvrissement de la qualit du logiciel, un retard de livraison, et des solutions qui ne satisfont pas les besoins du client. [Knoernschild 2008]

L'intgration continue est une rponse logique aux problmes prcits, et a beaucoup volu depuis sa conception. Au dpart, on parlait de Daily Build qui tait devenu un standard. Maintenant, on part du principe qu'un build est effectu chaque jour et/ou chaque fois qu'un changement significatif est apport au projet. [Extreme Programming 2009] Le terme Continuous Integration est apparu la premire fois dans une des douze pratiques du processus de dveloppement de Extreme Programming . Les principes peuvent tre cependant appliqus chaque modle de programmation itrative (comme Agile par exemple). Kent Beck, le crateur d'XP (Extreme Programming) ainsi que Martin Fowler, spcialiste reconnu des mthodologies de dveloppement, ont t les premiers crire des articles traitant du sujet la fin des annes 1990. Le processus d'intgration n'est pas un problme rcent, mais comme la complexit des projets augmente avec le temps, le besoin d'intgrer rgulirement et de s'assurer que les modules fonctionnent ensemble est devenu prioritaire. La consquence de ce besoin fut le dveloppement de pratiques pour s'assurer une intgration rgulire et fiable, et donc la naissance du concept d'intgration continue . 2.3 Avantages

On peut citer de nombreux avantages dcoulant d'un usage efficient de l'IC: L'argument principal reste le fait que l'IC rduit les risques les tests et les inspections permettent de dtecter automatiquement les dfauts ds qu'ils sont commit dans le repository , et donc de les corriger directement. Le fait

2 Prsentation gnrale du concept dIC

d'instaurer une routine de tests, dans un environnement stable, permet aussi de rduire les doutes quant la fiabilit du systme. Une meilleure visibilit dans le projet l'IC a pour vocation premire une participation accrue des diffrents acteurs : mettre en place une infrastructure pour le partage d'informations, centraliser les donnes et les labliser dans le repository afin d'en avoir une meilleure vision d'ensemble, privilgier le code comment pour que d'autres dveloppeurs puissent y accder plus facilement, recevoir les informations lies au rsultat du build , etc. Toute cette mise en place permet de prendre des dcisions en connaissance de cause tant donn que toutes les informations pertinentes sont disponibles. Cette visibilit permet en outre d'acqurir une certaine confiance des dveloppeurs, ceux-ci se sentent rassurs puisqu'ils connaissent l'impact que leur code, mme corrompu, peut avoir sur le systme. Ils savent que le corriger devient plus ais, qu'il est mme possible de revenir une version antrieure. Ils prennent donc plus souvent l'initiative de faire un changement. Il faut aussi savoir que de nombreux outils, souvent associs au serveur d'intgration, sont disponibles afin d'avoir une vue globale du code-source, et de pouvoir y associer une meilleure analyse (par exemple un diteur UML qui gnre des diagrammes partir du code-source dans Javadocs, un gnrateur de documentation technique (Doxygen), un outil d'analyse statique des donnes mtriques (Panopticode), etc.). Rduire les processus rptitifs le propre de l'IC est d'instaurer un processus ordonn, en automatisant des tapes on vite un surplus de travail au dveloppeur. Gnrer un logiciel dployable l'avantage indniable de l'IC est le fait de pouvoir gnrer un excutable du logiciel n'importe quand, ds qu'un changement est effectu sur le repository une nouvelle version du logiciel est cre. Cela permet donc de dtecter les erreurs au plus vite. Cette mthode influe aussi sur la confiance des dveloppeurs: il arrive parfois qu'ils avancent dans leur travail sans mme savoir si le build va se faire, on pourrait presque parler dans ce cas de procrastination des programmeurs qui repoussent sans cesse l'chance du build. C'est pourquoi on parle souvent d' integration hell (l'enfer de l'intgration) [Duvall 2007] puisque la phase d'intgration a toujours t la cause d'importants retards, rarement comptabilise l'chance et ceci peut tre vit avec l'IC. Ces

2 Prsentation gnrale du concept dIC

excutables sont galement essentiels pour le client qui peut constater au jour le jour les avances de son programme et ainsi redfinir au mieux ses besoins. Programme de meilleure qualit la qualit est ce qui est recherche au travers de l'IC. On peut dfinir la qualit comme la pondration des spcifications d'un logiciel suivantes: Extensibilit, scurit, performance, capacit tre maintenu, lisibilit, etc. cf. [Duvall 2007, p.28] Plusieurs caractristiques de l'IC contribuent obtenir un code fiable. On peut par exemple dtecter une duplication du code, appliquer un standard ou une convention dans le dveloppement du code, etc. De nombreux points seront dvelopps plus loin, dans les dispositifs mettre en place pour l'laboration de l'IC. 2.4 Dsavantages

(Ou les ides reues qui incitent les quipes de dveloppement opter pour le statu quo) Le changement bien entendu le changement n'est jamais ais grer pour un dveloppeur qui a dj ses habitudes. L'ide serait de faire une transition pas--pas (par exemple diminuer le nombre de tests, intgrer des frquences moins importantes ou revenir au standard qu'tait le daily build le temps de l'adaptation). Travailler avec quelqu'un qui a de l'exprience dans l'IC permet aussi de passer le cap avec plus de facilit. Cots supplmentaires le seul investissement serait une machine pour l'intgration, de nombreux logiciels pour la mise en place du dispositif tant disponibles gratuitement sur internet. Il va de soi que l'investissement en vaut la chandelle compar tous les cots quimplique la dcouverte tardive d'un dfaut (bug). De plus, il n'est pas non plus ncessaire d'acheter un ordinateur dernire gnration pour un projet de petite/moyenne ampleur. On peroit ici l'importance d'une vision long terme pour une entreprise : en investissant pour une machine, la comptabilit de l'entreprise ne percevra pas immdiatement un retour sur investissement, d'autant qu'une priode d'adaptation cette mthodologie est indispensable pour en tirer les premiers bnfices (on en revient la problmatique du changement cite auparavant).

2 Prsentation gnrale du concept dIC

Le nombre de builds qui chouent ou leur lenteur d'excution s'ils chouent, c'est souvent les tests qui en sont la cause. La solution serait d'effectuer un build priv avant de commiter dans le repository , les tests seraient donc effectus en interne. Ce dsavantage n'en est videmment pas un, vu que le build priv fait partie des bonnes pratiques de l'IC. De plus, il est plus facile de corriger un build effectu rgulirement, qui ne contiendrait que peu d'erreurs (vu que les changements ne sont pas importants) qu'un build hebdomadaire dont les changements ne sont pas connus de tous les dveloppeurs. Pour ce qui est de la lenteur d'excution, on peut facilement parer ce problme en partitionnant les builds (cf. Chapitre 5.2.12 pour les dtails) et en les invoquant selon le besoin.

Migration le passage dun large volume de projets de dveloppement dans un environnement dIC (projets qui sont souvent rpartis dans de nombreux environnements de dveloppement) requiert un planning et une coordination efficace pour que la migration soit russie.

2.5

Les difficults de la mise en place

L'intgration continue est une solution idale pour les petites quipes de dveloppement. Comme nous allons le voir, il aide maintenir tous les acteurs informs des derniers changements. Il permet aussi toutes les quipes gravitant autour du projet d'obtenir l'information de la version qu'elles recherchent. Cependant, de nombreux facteurs pourraient amener des difficults quant la mise en place d'un tel systme: Sur un plan matriel: Les capacits de stockage ou de bande passante La puissance du processeur du serveur d'intgration La taille et la performance du repository Les dpendances entre les diffrents fichiers lors du build Etc.

Sur un plan organisationnel: Les relations entre les sous-quipes et le rythme o chaque intgration est lance

2 Prsentation gnrale du concept dIC Les quipes disperses gographiquement (horaires diffrents) Etc.

10

Les projets de plus grande envergure amnent souvent rorganiser les quipes afin de leur attribuer des sous-projets . Cette particularit change la faon dont on structurera l'environnement de dveloppement. Chaque quipe, charge d'un sous-projet, sera responsable de dlivrer un code ou des excutables fonctionnels afin que toutes les autres quipes puissent, au besoin, les rutiliser. Chacun sera cependant responsable de son propre code et ne modifiera pas celui des autres.

3 Prsentation des diffrents environnements dans lIC.

11

Prsentation des diffrents environnements dans lIC.

Il est important, dans un premier temps de visualiser et comprendre les tapes quimplique la programmation d'un logiciel dans un environnement dIC typique. La Figure 3-1 en donne un parfait aperu. Elle s'articule autour de 5 tapes dcrites cidessous.

Figure 3-1 : Les composants dun systme dIC, [Duvall 2007, p. 5]

Les termes utiliss sont pour la plupart conservs en anglais, puisqu'ils sont entrs dans le jargon d'informatique et que souvent, aucun terme franais ne leur correspond.

1. Chaque dveloppeur travaille sur son propre poste. Il devra dans un premier temps effectuer un check out du contrle de versionnement, ce qui signifie qu'il importera sur sa machine la dernire version du programme qui rside dans le repository . 2. Une fois qu'il a effectu un changement significatif sur le code-source, il effectuera le chemin inverse: c'est--dire qu'il exportera son travail dans le repository pour le mettre disposition des autres dveloppeurs. On dit qu'il

3 Prsentation des diffrents environnements dans lIC.

12

commit son code. Habituellement, le dveloppeur passe par une tape intermdiaire qui consiste lancer un private build avant son commit , c'est--dire qu'il contrlera sur son poste que les changements qu'il a effectu permettront de conserver une version saine du programme avant de mettre son travail en commun. 3. Le Serveur IC est la machine qui fera le build , il s'agit en fait de compiler, tester, inspecter et dployer le code-source, donc de vrifier que le logiciel fonctionne de manire fiable. Le rle de ce serveur sera de contrler ( poll , scruter en franais) rgulirement s'il y a une nouvelle version du code-source prsente dans le repository auquel cas il excutera le Build Script qui consiste lancer les diffrentes tapes du build . Ce serveur n'est pas indispensable au bon fonctionnement de l'IC, puisqu'il est possible d'crire manuellement tous les Build Script et de forcer le build d'intgration quand un changement a lieu dans le repository . Il est cependant plus ais de profiter des avantages que le serveur met disposition, quitte devoir adapter certains scripts manuellement, d'autant plus que de nombreux serveurs d'intgration sont disponibles, certains mme gratuitement (comme CruiseControl.NET qui sera utilis pour la partie pratique). 4. Le Build Script est un fichier de configuration utilis pour compiler, intgrer la base de donnes, tester, lancer linspection et dployer le programme. On peut automatiser le cycle du build du programme sans forcment que ce soit dans le cadre d'une implantation de IC : Ant, Nant, etc. en sont un parfait exemple. 5. Une fois le build effectu, le serveur dIC gnre des feedbacks pour informer les dveloppeurs du rsultat. Il peut s'agir d'un courriel, d'un sms, d'un son, etc. avertissant les utilisateurs concerns de la russite ou de l'chec du build , de nombreuses autres informations peuvent galement tre envoyes. Ce point sera dvelopp plus en profondeur dans la partie traitant des dispositifs (cf. Chapitre 4.6 pour les dtails).

4 Prsentations des 6 dispositifs qui dfinissent lIC.

13

Prsentations des 6 dispositifs qui dfinissent lIC.

Aprs les diffrents environnements, nous allons maintenant nous attarder sur ce quimplique le fait dutiliser un systme dIC : il sagit en fait de 5 tapes successives par lesquelles le code-source va passer, puis du feed-back qui informera le dveloppeur de lissue du build. 4.1 Compilation du code-source

Selon le Larousse, la dfinition de compilation est la traduction d'un programme crit en langage volu en un programme quivalent en langage machine (c'est--dire en un code binaire). [Larousse, 2010] L'objectif est donc qu'il soit lisible et autonome (donc excutable) pour le processeur. Une fois compil, le programme sera plus rapide l'excution. Il faudra nanmoins le recompiler nouveau si on modifie le fichier source afin que toutes les modifications puissent tre effectives. Pour les langages dynamiques que sont PHP ou Ruby, qui sont des langages dits interprts, on ne peut pas vritablement parler de compilation puisqu'ils ne gnrent aucun code binaire. Ils sont traduits au fur et mesure par un interprteur qui est simplement un programme auxiliaire. [Duvall 2007, p.12] Idem pour les langages dits intermdiaires qui peuvent subir une phase de compilation intermdiaire vers un fichier crit dans un langage qui n'est pas intelligible et nonexcutable (par exemple un applet Java qui ncessite un navigateur internet pour tre excut, alors mme qu'il est compil).

Dans le cadre de l'IC, on ne fera pas de diffrenciation entre ces langages. Mme si la compilation n'est pas effective. Cette tape permet pour certains langages dynamiques d'excuter un processus de contrle qui peut tre assimil une compilation dans ce contexte particulier. 4.2 Intgration de la base de donnes

Dans cette tape, on parlera de Continuous Database Integration (CDBI), qui est simplement l'application de l'IC au niveau de la base de donnes (BD). En d'autres termes, le processus d'intgration reste le mme que pour le code-source: on appliquera

4 Prsentations des 6 dispositifs qui dfinissent lIC.

14

les changements la BD dans le repository pour qu'un nouveau build puisse se faire, on testera (les procdures, les fonctions, les interactions des contraintes, etc.), on inspectera (l'intgrit des donnes, la performance, les conventions/standards de nommage, etc...), on dploiera (la BD aux instances de dveloppement et de tests de la BD) et on recevra un feedback en retour. Le problme ici reste bien entendu que le code-source et la BD ont souvent des dpendances qui compliquent le processus d'automatisation. Le but de l'automatisation est de soulager les membres de l'quipe de dveloppement, leur viter des tches rptitives qui reprsentent, terme, une perte de temps vitable. Paul M. Duvall a numr toutes les activits rptitives que l'on pourrait associer au CDBI , celles-ci reprsentent quasiment toutes les commandes de bases lies la manipulation des donnes dans une BD: supprimer/crer une BD, supprimer/insrer une donne dans le systme, migrer une BD/donne, modifier une donne/procdure/permission d'accs, etc... cf. [Duvall 2007, p. 111]

Ces tapes permettent surtout de dcharger une personne en particulier: le DBA (pour DataBase Administrator, ou Administrateur de BD). Donner la possibilit aux dveloppeurs de modifier eux-mmes certaines tches basiques lui permet de se concentrer davantage sur la normalisation des donnes, le dveloppement de standard ou l'amlioration des performances. Cela permet en outre d'intgrer au mieux le DBA comme membre de l'quipe de dveloppement et cela vite aussi au dveloppeur de perdre du temps contacter un intermdiaire pour un changement qu'il est capable de faire lui-mme. Ce changement implique certaines conditions nanmoins:

Que le programmateur travaille dans un environnement priv, et qu'il ne commit qu'une fois que tous les tests passent avec succs. Il prend donc la responsabilit de dlivrer au repository une BD stable.

Que le DBA supervise les changements une fois qu'ils ont eu lieu, et qu'il dtecte les causes d'une ventuelle erreur.

4 Prsentations des 6 dispositifs qui dfinissent lIC. 4.2.1 Local Sandbox

15

Comme il a t dit plus haut, le danger de l'intgration de la BD, c'est les dpendances systme. Un changement effectu dans la structure d'une BD partage peut amener les private build des autres dveloppeurs chouer. Cette problmatique a incit les chefs de projet revoir l'environnement de dveloppement. Il s'agit de concevoir la BD comme le code-source: lors du check out du repository, on inclut la BD afin de travailler en vase clos le temps que les tests confirment que les changements n'affecteront pas le build des autres dveloppeurs. Le DB Sandbox consiste donc en une BD locale qui est une copie conforme de la BD originelle. cf. [Duvall 2007, p. 117]

Figure 4-1: Exemple de lutilisation dun local sandbox pour chaque dveloppeur, [Duvall 2007, p. 118] 4.2.2 Les bonnes pratiques

1. Une des pratiques adopter pour le CDBI c'est l'envoi dans le repository de tous les fichiers lis la BD: les configurations spcifiques de la BD, les procdures et les fonctions, les scripts Data Definition Language (DDL), les scripts Data Manipulation Language (DML), les diagrammes entit-association, ou les tests.

4 Prsentations des 6 dispositifs qui dfinissent lIC.

16

L'objectif est de pouvoir reconstruire la BD partir de zro, grce aux fichiers laisss sur le repository. cf. [Duvall 2007, p. 120] 2. Une autre pratique serait de faire une mise jour automatique des BD Sandbox des dveloppeurs. Ds qu'un changement est effectu dans la BD principale, un check out s'effectue chez chacun afin de rester synchroniser avec le repository. Ceci implique forcment de rester connect au rseau, ou du moins de faire une requte de mise jour manuelle rgulirement. cf. [Duvall 2007, p. 110] 3. Refactoriser la BD: on peut le dfinir comme la maintenance du code de la BD, c'est-dire supprimer les redondances, simplifier le code, limiter la complexit, etc. C'est une technique bien connue mais qui implique beaucoup plus d'attention en ce qui concerne les BD, puisque la refactorisation implique 3 changements simultans: cf. [Duvall 2007, p. 120] Changer le schma de la BD Migrer les donnes dans la BD Changer les codes d'accs de la BD

4. Intgrer la BD Sandbox rgulirement: de nombreuses pratiques peuvent tre reprises de l'IC applique au code-source. On peut donc se rfrer au Chapitre 5 pour plus d'informations. 4.3 Lancer les tests

Dans cette tape, le but sera d'incorporer des tests automatiques dans le processus du build. L'chec d'un seul des tests provoquera l'chec complet du build. Le but ici sera de rendre un programme fiable 100%. Comme le prcise Paul M. Duvall, la fiabilit thorique totale d'un systme se calcule par le produit de la fiabilit de tous ses composants. Par exemple, si la valeur de fiabilit de 3 composants-systme est value 90%, le systme entier ne sera pas fiable 90%, mais bien 73% (0.9 * 0.9 * 0.9). Les routines de tests sont l justement pour rendre un niveau de fiabilit optimal: plus le code-source est encadr de tests pertinents, plus il sera considr comme fiable . cf. [Duvall 2007, p. 131]

Imperfect tests, run frequently, are much better than perfect tests that are never written at all. [Fowler 2008]

4 Prsentations des 6 dispositifs qui dfinissent lIC.

17

On peut catgoriser les tests en 4 groupes diffrents selon les phases de dveloppement dans lesquels on se situe: 4.3.1 Tests unitaires

Par unitaire on suppose qu'on a affaire une portion de programme. On teste un module pour s'assurer qu'il fonctionne en toutes circonstances par rapport aux spcificits exiges. Ces modules peuvent avoir des dpendances les uns avec les autres. Dans ce cas, on supposera que ces dpendances sont minimales et n'impliquent en aucune manire des objets graphiques ou des bases de donnes. La caractristique principale des tests unitaires est leur temps d'excution rapide. 4.3.2 Tests dintgration

Le but ici est de vrifier l'interaction entre les diffrents composants que chaque dveloppeur a conus pour produire un ensemble dont le comportement correspond aux modifications effectues. Les diffrences principales avec les tests unitaires rsident dans le fait que la base de donnes sous-jacente, les dpendances systme ou le rseau seront ncessaires. Ils ne sont cependant pas considrs comme des tests de haut niveau. Tests dintgration : tests effectus pour montrer des dfauts dans les interfaces et interactions de composants ou systmes intgrs. [CFTL 2009] 4.3.3 Tests systme

Ces tests vrifient que les interfaces externes comme les services Web fonctionnent comme prvu. Les dpendances externes rendent ce genre de test beaucoup plus coteux au niveau du temps d'attente, on les effectue d'ailleurs principalement de nuit ou durant une priode de pause. Quand les tests d'intgration sont dvelopps dans le but de tester les interfaces entre les composants, les tests systme voluent dans un environnement contrl et configur, les diffrents tests sont donc dvelopps pour simuler des scnarios de la vraie vie qui sont effectus dans un environnement de test ayant justement pour charge de simuler cette vraie vie . Une autre diffrence rside dans le fait que l'objectif des tests d'intgration est de s'assurer que les diffrents composants de l'application rpondent aux exigences du

4 Prsentations des 6 dispositifs qui dfinissent lIC.

18

client, tandis que celui des tests systme, c'est de valider l'exactitude et la perfection de l'application dans l'accomplissement des fonctions prvues et dans le test de toutes les fonctions requises dans la vraie vie . cf. [Duvall 2007, p. 136] Tests systme : le processus de test dun systme intgr pour vrifier quil rponde des exigences spcifiques [CFTL 2009] 4.3.4 Tests fonctionnels (ou dacceptation)

On cherchera ici tester le systme dans les conditions dfinies par le client. C'est donc ce stade qu'on testera si l'excutable rpond aux dfinitions du besoin que l'acheteur a mis. On tchera donc de mettre les incohrences ou les omissions en vidence avant la mise en uvre oprationnelle du systme. Test dacceptation : test formel en rapport avec les besoins, exigences et processus mtier, conduit pour dterminer si un systme satisfait ou non aux critres dacceptation et permettre aux utilisateurs, clients ou autres entits autorises de dterminer lacceptation ou non du systme [CFTL 2009]

L'objectif de la catgorisation des tests de dveloppement dans le cadre de l'IC est simplement de permettre un rsultat plus rapide: plus il y a de dpendances entre les composants (bases de donne, Web ou fichiers systme par exemple), plus les tests prendront du temps tre effectus. A partir de l, on lancera des tests unitaires beaucoup plus souvent que les tests d'intgration ou que les tests systme (qu'on effectuera lors de build secondaire (cf. Chapitre 5.2)) 4.3.5 Defect Driven Development

Une des bonnes pratiques de lIC est de faire chouer le build le plus rapidement possible (afin de dtecter au plus vite les erreurs). Le Defect Driven Development peut paratre tout aussi paradoxal: pourquoi commencer crire des tests destins chouer? Paul M. Duvall crit, dans le livre dj cit: Defects don't drive development-preventing those nasty aberration drives development! [Duvall 2007, p. 144] . Donc pour progresser dans le dveloppement, il faut pouvoir prvenir la survenue des dfauts, car on pardonne plus facilement 1000 erreurs diffrentes que 1000 fois la mme erreur. Il s'agit donc d'viter de corriger une erreur et qu'elle rapparaisse sous une mme forme

4 Prsentations des 6 dispositifs qui dfinissent lIC.

19

quelques temps plus tard. Il faudra par consquent lancer un test qui expose le problme au grand jour et partir de l, il pourra tre corrig. La difficult consiste donc crire un test qui choue selon les conditions voulues. On corrigera ds lors le code source de faon ce que ce test choue. L'objectif sera non seulement de corriger le dfaut, mais surtout de prvenir des erreurs rcurrentes. 4.4 Inspection

L'un des avantages rsultant de l'utilisation de l'IC tait que le programme ressortait souvent de meilleure qualit. Cette qualit on la doit essentiellement la batterie de tests et d'analyse qui dcoulent de cette tape. Quand on parle de lancer l'inspection , il s'agit en fait de contrler si les standards de grammaire du code sont respects, contrler l'adhrence des diffrentes couches architecturales ou le degr de duplication du code, ainsi que gnrer des donnes qui permettront d'amliorer le code. Il est parfois difficile de diffrencier le test de l'inspection. On remarquera simplement que les deux tapes ne changent pas le code lui-mme, elles mettent simplement en exergue les anomalies, bugs ou changements apporter pour amliorer le programme. Les diffrences sont dans la systmatique des outils utiliss. Les tests sont dynamiques: on excutera le programme afin de tester ses fonctionnalits. L'inspection agit de manire plus systmatique, en fonction d'un set de rgles prdfinies: c'est un ensemble d'outils d'analyse statique et dynamique, le but tant d'arriver un standard auquel tous les dveloppeurs adhrent (ce standard pouvant varier selon les quipes de dveloppement, ces outils sont donc parfaitement paramtrables).

Le gros avantage de l'inspection telle qu'on l'applique dans l'IC, c'est qu'on met de ct le subjectivisme de l'Homme au profit de la logique implacable de l'ordinateur. Le pair programming (c'est--dire la programmation par quipe de deux qui est lune des mthodes de dveloppement proposes dans XP) illustre parfaitement le ct subjectif de la mthode. Ces tests ont le mrite dtre rigoureux, rptitifs et surtout appliqus de faon rendre une rponse standard un mme problme rencontr plusieurs fois. Automatiss et fiables, ces outils nont donc plus besoin d'intervention humaine. On permet ainsi, comme dans la partie test et intgration de la BD , d'pargner au programmeur les tches fastidieuses lies cette tape afin qu'il puisse se consacrer la correction proprement parler.

4 Prsentations des 6 dispositifs qui dfinissent lIC.

20

Observons plus en dtails les diffrents tests dvolus l'inspection du code:

Rduire la complexit du code:

La question est: Comment identifier un code complexe? . On utilisera la donne appele Cyclomatic Complexity Numbers ou CCN (issue des recherches de Thomas McCabe abouties en 1970) qui est le nombre qui mesure la complexit en comptant le nombre de chemins distincts d'une mthode. Par exemple, chaque if , while , for , etc. rajoutera 1 au degr de complexit de la mthode. cf. [rkcole 2009] Son tude dbouche sur le fait que plus le degr de complexit est lev, plus le risque d'erreur est important. Quelques outils (comme JavaNCSS) permettent de dterminer la longueur des mthodes ainsi que le nombre de lignes de code non-commentes. Il y a deux moyens de rduire les risques lis la complexit : Augmenter le nombre de tests unitaires pour les mthodes plus complexes (l'idal serait d'avoir un nombre de tests quivalent au degr de complexit, du moins de s'en rapprocher) Refactorer le code en plusieurs parties, cela permet de partager la complexit en plus petites tapes, plus grable et donc en mthode qu'on pourra tester avec plus de facilit. Exemple:

void printOwing() { printBanner();

//print details System.out.println ("name: System.out.println ("amount } " + _name); " + getOutstanding());

4 Prsentations des 6 dispositifs qui dfinissent lIC. void printOwing() { printBanner(); printDetails(getOutstanding()); }

21

void printDetails (double outstanding) { System.out.println ("name: System.out.println ("amount } " + _name); " + outstanding); [Refactoring 2009]

Appliquer des standards de dveloppement.

Avoir des rgles permettant aux dveloppeurs d'avoir une mthodologie de travail est quelque chose d'essentiel. Il permet une certaine indpendance de programmation vu que si l'on reprend le code d'un collgue, on pourra s'y retrouver peu importe les circonstances. Plusieurs outils d'analyse sont disponibles, le plus connu tant PMD pour la plateforme Java. Il permet de rgler ses prfrences au niveau des conventions de nommage, de design, d'architecture ou simplement de code qui n'est pas utilis. cf. [Duvall 2007, p. 173]

Rduire le code dupliqu.

Le phnomne copier-coller n'est pas nouveau dans le domaine de la programmation. Mme si le dveloppement de langage orient-objet ou de la programmation procdurale permettrait, en thorie, d'radiquer le problme, le programmateur tombe souvent dans la facilit. La perte de temps trouver, analyser et corriger un code qu'on retrouve de nombreux endroits, suivi de l'incertitude de les avoir tous identifis, ainsi que les cots inhrents au dveloppement de tests du code additionnel, devraient suffire inciter le dveloppeur se concentrer davantage sur le problme. A nouveau des programmes de tests permettent d'identifier ces portions de codes qui se rptent. PMD (cit auparavant) offre d'ailleurs un Copy-Paste Detector (CPD) dans son escarcelle de paramtres personnalisables. cf. [Duvall 2007, p. 176]

4 Prsentations des 6 dispositifs qui dfinissent lIC.

22

Connatre la couverture du code.

Il s'agit simplement de calculer la quantit de lignes impliques lors d'un test d'une mthode. On peut mettre ce chiffre en relation avec le nombre total de lignes de la mthode pour connatre la couverture du code. Par exemple si une mthode 100 lignes, et 35 seulement sont utilises pour le test, on dira qu'elle a une couverture de 35%. Il va sans dire que l'objectif est de se rapprocher des 100%. De nombreuses autres techniques permettent d'estimer la couverture des tests: function qui calcule le nombre de fonctions utilises, branch qui calcule si toutes les diffrentes options d'un if/else (par exemple) sont prises en compte, condition , entry/exit , loop ou path . Toutes ces informations peuvent tre utiles selon les besoins du programmateur qui souhaite optimiser ses tests. De nombreux outils sont d'ailleurs disponibles: Junit, Ncover, Clover.NET ou EMMA, pour ne citer qu'eux. cf. [Di-ENSLabatut 2007]

Cette information peut tre particulirement utile pour le Chef de projet, qui fixe l'avance un seuil ou un quota de couverture du code par des tests afin de garantir une certaine qualit du programme. Il peut ds lors comparer la diffrence de couverture d'une intgration l'autre, et analyser le pourquoi d'une ventuelle baisse (le programme augmentant en terme de lignes de code, mais la quantit de tests de suit pas, ou bien certains tests ont t enlevs ou n'ont plus de rfrence claire au code)

Il y a une quantit incroyable de donnes qui pourraient tre analyses pour amliorer la qualit du programme. L'important tant de dcider quelle information est pertinente pour l'quipe de dveloppement, pour l'quipe de l'Assurance Qualit, pour le manager ou le client. Le seul objectif doit tre la recherche de la qualit: via des routines de tests et des feedbacks rapides, les dveloppeurs peuvent se concentrer sur des tches ncessitant une analyse plus fine du code. 4.5 Dploiement

Lorsqu'on parle de dveloppement de logiciel, il va sans dire que l'unique objectif est de dployer un logiciel fonctionnel. Toutes les tapes qui prcdent celle-ci (et celle qui lui

4 Prsentations des 6 dispositifs qui dfinissent lIC.

23

succde) n'ont pour but que de faciliter le dploiement, et de le rendre oprationnel peu importe l'environnement sur lequel il tourne.

Paul M. Duvall parle de 6 tapes caractristiques lors du dploiement d'un logiciel dans le cadre d'une IC cf. [Duvall 2007, p. 191] : 4.5.1 Etiqueter les donnes du repository

Etiqueter les diffrentes versions permet d'identifier et suivre l'volution d'un groupe de fichiers. 4.5.2 Produire dans un environnement sain

Le but ici est de s'assurer que le systme d'exploitation, les logiciels installs, les scripts, la configuration du systme ou du serveur n'entrent pas en conflit avec le logiciel dploy. La solution est de partir de zro (rien sur le systme) puis de tester pas--pas le logiciel en appliquant une couche aprs l'autre, ou plus fiable encore, de lancer un processus automatis qui appliquerait et supprimerait toutes les couches pour avoir la certitude qu'elles sont bien compatibles les unes avec les autres. 4.5.3 Gnrer et tiqueter un build issu du repository Labeling a build is as simple as performing a full build and assigning an identification to it [Duvall 2007, p. 196] La diffrence entre labliser un build et une version dans le repository rside simplement dans le fait que le build est un excutable, un fichier .zip ou .jar dj compil. Le contenu du repository n'est qu'un groupement de fichiers non-binaires qui n'est souvent pas encore compils. Comme pour le repository, le but est une meilleure communication entre les diffrents organes de production, pouvoir faire un historique de chaque build et bien sr, la possibilit de revenir en arrire en cas d'chec.

4 Prsentations des 6 dispositifs qui dfinissent lIC. 4.5.4

24

Lancer des tests de tous niveaux dans un clne de lenvironnement de production

Il s'agit l de tester sur un environnement sain (qui sera le clone de l'environnement de production) que tous les tests passent avec succs. Cette batterie de tests (dj effectu dans une autre phase de l'IC) permet simplement de s'assurer (une nouvelle fois) que le logiciel est performant, ceci dans un environnement diffrent. Ces tests sont aussi effectus pour rassurer les dveloppeurs: un dveloppeur confiant est souvent un dveloppeur performant. 4.5.5 Crer des feedbacks pour le build

Le feedback est la base de l'IC. Avoir un retour de l'information permet : aux dveloppeurs d'avoir un rapport sur ce quoi faire ? pour corriger les ventuels dfauts aux clients de savoir dans quelle phase de dveloppement se trouve leur commande au chef de projet d'avoir une vue d'ensemble sur ce qui exige encore des amliorations. On ne le dira jamais assez, une bonne communication tous les chelons de production permet d'viter les malentendus et de grer au mieux les chances. 4.5.6 Possibilit de revenir une version prcdente

La capacit de revenir une version prcdente est une option trs importante dans le processus de dveloppement, galement pour comprendre les erreurs qui ont men un broken build . Cette tape implique que les builds ou le repository ont bien t tiquets. 4.6 Feedback

Afin de grer au mieux l'mission de feedbacks, on articulera notre choix sur quatre branches distinctes, comme l'a prsent Paul M. Duvall dans son livre.

4 Prsentations des 6 dispositifs qui dfinissent lIC.

25

Figure 4-2: Le feedback comme Paul M. Duvall le conoit, [Duvall 2007, p. 206] 4.6.1 Les bonnes informations

De nombreuses informations sont gnres: les rsultats de tous les tests de la phase du mme nom, ceux des outils d'analyse statique de la phase d'inspection, ou simplement celui de la russite ou non du build . Toutes ces informations n'intressent bien sr pas tous les acteurs du projet et on peut facilement rpartir les informations pertinentes pour chacun. 4.6.2 Les bonnes personnes

De nombreuses personnes sont intresses au rsultat d'un build, commencer par le testeur qui s'intressera aux rsultats de la phase de tests et celle de l' inspection afin de peaufiner ses propres requtes. Le dveloppeur, le chef de projet,

4 Prsentations des 6 dispositifs qui dfinissent lIC.

26

le responsable du build ou simplement le client, tous ces acteurs ont un intrt dans la bonne marche du projet. Certains prfreront recevoir une alerte quand il y a un problme dans le processus d'intgration, d'autres uniquement quand le build russit: l'essentiel tant de ne pas envoyer trop d'informations aux acteurs au risque qu'ils ignorent carrment les messages d'alerte, tellement ils en reoivent. 4.6.3 Le bon moment

L'objectif principal de l'IC, au-del de la qualit, est le gain de temps. Rduire au maximum le temps entre la dcouverte d'une faille ou d'un code incorrect, et sa correction. On dcouvre les erreurs grce aux routines de tests, on les corrige grce aux feedbacks qui sont gnrs. Donc, plus on attend pour envoyer l'information, plus le problme tardera tre rsolu. Ici le bon moment sera donc le plus vite possible pour les personnes qui sont concernes par la correction de ces erreurs. 4.6.4 La bonne manire

C'est peut-tre la partie la plus ludique du processus: chacun la possibilit de choisir la manire dont il veut que l'information lui soit transmise. Certains opteront pour un simple e-mail ou un sms (de telles options peuvent tre choisies d'un simple clic via la majorit des serveurs d'intgration du march). D'autres gadgets permettent aussi d'informer sur le statut du build: l'orbe qui s'illumine (et dont la couleur pourrait mme clairer sur la russite ou l'chec du build), un son, une icne sur la barre des tches ou mme une fentre qui s'ouvre via sa messagerie instantane (MSN, AIM, Yahoo, etc...). Au-del de l'aspect rcratif de la manire dont l'information nous parvient, il est clair que si l'on travaille dans un bureau bruyant, on n'optera pas pour un son qu'on ne pourra peut-tre mme pas entendre, la mme chose pour un sms dans un immeuble qui ne capte pas de rseau. Le but est bien entendu de limiter le temps entre la dcouverte et la rsolution. On choisira ds lors l'outil le plus adapt nos besoins, avec de la fantaisie si cela est possible.

5 Outils et automatismes adopter pour une IC idale

27

Outils et automatismes adopter pour une IC idale

Ce chapitre reprsente une sorte de guide des bonnes pratiques pour installer un systme dIC optimal et les outils informatiques ncessaires pour y parvenir. On tchera ainsi de rpondre aux questions suivantes, prsentes dans lintroduction. Quelles sont les habitudes acqurir, les pratiques adopter pour une IC idale? 5.1 5.1.1 Quels outils pour l'IC? Rflexes avoir pour le repository Utiliser le repository pour stocker tous les fichiers

On pourrait sattendre ce que les fichiers du code-source soient les seuls ayant besoin dtre centraliss. Cependant, et afin d'viter des commentaires du genre pourtant a marchait sur ma machine! , il est important d'inclure dans son repository tous les fichiers tels que : build les fichiers de donnes pour initialiser une application les JAR, les librairies, les DLLs les fichiers de configurations les builds scripts ainsi que les paramtres d'environnement du

Le fait que l'environnement soit connu et que les fichiers soient les mmes pour tous permet d'amliorer la standardisation de la production et que tous les dveloppeurs aient un environnement stable de production.

Everything should be in the repository [Fowler 2008]

5.1.2

La Staging Area

Le meilleur moyen de coordonner des dpendances multiples lies au build est d'utiliser une Staging Area . On pourrait assimiler cette pratique une sandbox (cf. Chapitre 4.2.1) rserve tous les composants dont sont dpendants le build et les tests.

5 Outils et automatismes adopter pour une IC idale Comment a marche?

28

Chaque quipe dveloppe son sous-projet sans se soucier des autres: lance des builds, compile et commit dans le repository commun.

A une certaine chance, ces quipes mettent en commun les librairies, les APIs, ou le fichier de configuration dont les autres pourraient avoir besoin.

Lorsque le build est effectu dans lespace de travail personnel du dveloppeur ou mme dans le serveur d'intgration de l'quipe, tous les fichiers qui concernent lenvironnement de dveloppement du build pointent vers la Staging Area qui permet de centraliser les informations. [Crossroads 2004] (voir la Figure 5-1 : La Staging Area [Crossroads 2004] ci-dessous)

Figure 5-1 : La Staging Area [Crossroads 2004]

La Staging Area est donc simplement une technique pour viter les dpendances d'interface des diffrentes quipes lors du build. On spare donc leur implmentation. L'environnement choisi permet donc de satisfaire les dpendances build et tests des diffrentes quipes de dveloppement.

5.2

Rflexes avoir pour le build

Eviter de se retrouver face un build qui choue, voil un objectif fondamental pour les quipes de dveloppement. Le plus important reste la frquence et la dure de ces checs puisque le processus d'IC s'arrtera tant que le build posera problme. Le but ici est de ne pas dmoraliser les programmeurs avec des interruptions gnralises dues

5 Outils et automatismes adopter pour une IC idale

29

lchec du build. La plupart du temps ces checs ne donnent pas vritablement de cls quant leur rsolution ou l'tat actuel du build. Ceci amne le dveloppeur viter de faire un check out pour mettre son espace de travail jour, et choisit donc d'intgrer son code le moins souvent possible. On se retrouve donc ignorer la rgle No 1 des bonnes pratiques adopter pour l'IC : un commit rgulier du code . Plus on repousse l'chance du build, plus les risques d'un chec sont grands, plus les quipes de dveloppement sont craintives quant au rsultat du build et plus ils viteront de commiter leur code. On tchera donc d'viter de se retrouver face ce cercle vicieux en adoptant quelques bonnes pratiques qui aideront la mise en place d'une IC idale. 5.2.1 Types de build Le private build

Ce build est lanc titre personnel et dans l'environnement local du dveloppeur. Il a pour but de s'assurer que le code ne contient aucune erreur avant sa mise en commun sur le repository. Il s'agit plus d'un build prventif et correspond parfaitement cette volont de partitionner au maximum l'environnement de dveloppement. L integration build

Ici on obtient un build complet destin toute l'quipe de dveloppement, et dont le code-source provient du repository. Martin Fowler parlera ici de staged build qui consiste en un partitionnage des tapes du build. cf. [Fowler 2008] D'abord le commit build , qui lancera la compilation ainsi que tous les tests unitaires. Ensuite, et seulement si le commit build est concluant, le secundary build lancera les tests composants, systme ou de performance (cf. Chapitre 4.3), ainsi que tous les tests d'inspection prdfinis. Ces builds secondaires (qui peuvent eux-mmes tre partitionns) dclenchent quant eux une routine de tests plus dtaille, il faudra donc plus de patience pour leur rsolution. Le staged build permet d'obtenir plus rapidement le rsultat du build afin d'tre plus ractif en cas d'erreur. Le release build

Il s'agit du build destin au client ou au dpartement qualit. Une autre routine de tests est lance telle que celle d'acceptation ou celle lie la performance de chargement. Ce build met en exergue un des grands avantages de l'IC: crer un logiciel dployable en tout temps. Ce build n'intervient en gnral qu' la fin d'une itration ou d'une autre tape importante. cf. [Duvall 2007, p. 80]

5 Outils et automatismes adopter pour une IC idale 5.2.2 Les faons de le lancer

30

Sur demande

L'utilisateur choisit lui-mme le moment de son intgration, c'est donc un processus manuel. Agend

On prvoit une date et une heure prcise laquelle l'intgration sera effectue. A chaque commit

Le serveur d'intgration scrutera un changement dans le repository et activera le processus d'intgration s'il en peroit un. Event-driven

Il s'agit cette fois du repository qui dclenche le processus en lieu et place du serveur d'intgration. Celui-ci s'activera ds qu'un changement prdfini a lieu. cf. [Duvall 2007, p. 81] 5.2.3 Automatiser le build

Le but de l'automatisation est toujours le mme: limiter au maximum l'intervention humaine pour les processus rptitifs et sujets erreur. En choisissant l'automatisation pour le build, on admet galement que de nombreuses options sont suggres: Est-ce un build priv? Est-ce qu'on recherche juste un feedback rapide? Est-ce que les changements qui ont t effectus sont significatifs et mritent un build complet? Etc. Il faut donc dterminer quels processus seront inclus dans le build script . cf. [BuildMeister 2009] 5.2.4 Lexcuter via une seule commande

Fowler et Duvall imaginaient le concept d'intgration comme un simple bouton qu'on presserait et qui gnrerait toutes les tapes dj cites dans la partie des dispositifs (cf. Chapitre 4 ) en arrire fond, et dont la rsultante serait le logiciel. Le site internet officiel ddi au livre de Paul M. Duvall porte mme ce nom

( www.integratebutton.com ). [Duvall WS 2009], cf. [Duvall 2007, p. 144]

5 Outils et automatismes adopter pour une IC idale 5.2.5 Crer de plus petites quipes en sparant les tapes de dveloppement

31

Le but ici est de sparer le projet en sous-projet, et donc de diviser l'quipe de dveloppement en sous-quipes. Si un build venait chouer avec une quipe de 100 personnes qui dpendent de ce rsultat, il est vident que les heures de dveloppement perdues seraient plus importantes que pour un build impliquant 10 personnes. On limite donc l'impact de l'chec et par consquent, on optimise les ressources disposition. L'autre avantage d'une quipe rduite est la communication entre dveloppeurs. Le site AnthillPro (socit de dveloppement de serveur d'IC) prsente la communication comme un facteur-cl dans le support des trois piliers du build sans douleur (pain free) [Anthillpro 2009]. Ces trois piliers seraient la rduction de la dure d'un projet se trouvant dans un tat d'chec, l'appui au travail engendr par cet chec, et la limitation du nombre de personnes concernes. 5.2.6 Attribuer un poste de Chef de build

Une bonne communication rend ce statut quelque peu inutile, nanmoins il est important de pouvoir compter sur quelqu'un en cas de problme. Son rle sera simplement de s'enqurir du rsultat du build et d'informer le responsable de lchec que du travail l'attend afin de rendre le logiciel nouveau fonctionnel. Une bonne communication rend ce statut quelque peu inutile, nanmoins il est important de pouvoir dsigner un responsable en cas de problme. 5.2.7 Sparer le build de lenvironnement de dveloppement IDE

On parlait prcdemment, dans le dploiement du logiciel, de l'importance d'avoir un environnement sain, une sorte de clone de l'environnement de production. Cette prcision a son importance quand il s'agit d'laborer le build script . Celui-ci ne doit en aucun cas dpendre de son IDE: le problme rsultant tant la dpendance du script sa propre configuration, alors que le but recherch est la standardisation de l'intgration par le serveur d'IC, et que celui-ci n'a que le systme oprationnel dinstall. cf. [Duvall 2007, p. 74] 5.2.8 Faire en sorte que les builds chouent rapidement

Bien sr il est prfrable de russir son build, nanmoins il faut partir du principe que le build a de grandes chances d'chouer, et que, dans ce cas, il vaut mieux qu'il choue le

5 Outils et automatismes adopter pour une IC idale

32

plus vite possible. Il faut dans un premier temps dterminer l'ordre dans lequel les diffrentes intgrations ou tests vont se drouler, en choisissant les parties susceptibles d'chouer le plus rapidement, ce qui peut varier selon le type de projet. 5.2.9 Faire quun build soit compatible peu importe lenvironnement

Il s'agit donc d'avoir un build efficient qui ne dpendrait pas de l'environnement. Pour cela on peut passer par diffrentes valeurs de configurations qui seront disponibles dans la plupart des environnements comme la configuration du serveur d'application, les informations lies la connexion de la base de donnes ou la configuration du Framework (espace de travail modulaire p.ex. Eclipse). La Figure 5-2 nous montre que mme si les environnements dans lesquels on travaille peuvent tre diffrents, le script utilis pour le build peut tre paramtr unilatralement pour amliorer la configurabilit du systme, afin quil puisse sadapter toutes les variations denvironnement.

Figure 5-2 : Le Build Script configur pour s'adapter chaque environnement, [Duvall 2007, p. 79] 5.2.10 Utiliser une machine ddie pour le build dintgration

Dans la partie des rflexes adopter pour le repository, le problme du Mais a marchait sur ma machine ! tait abord. Rduire voir supprimer les problmes lis la configuration est un dfi ralisable via une machine ddie pour le build dintgration.

5 Outils et automatismes adopter pour une IC idale

33

Le danger est naturellement que la configuration de sa machine ne corresponde pas celle des autres dveloppeurs et que le code-source quon importe sur le repository et dont lintgration tait russie, ne fonctionne plus sur la machine des autres dveloppeurs. Lide est de mettre en place une machine externe dont lenvironnement serait propre , cest--dire un environnement dintgration sans dpendance de code issu dune intgration prcdente (un script pourrait se charger de rendre lenvironnement un tat prdfini avant le commit du code). Ce dispositif permettrait galement de savoir si le dveloppeur a omis de commiter tous les fichiers ncessaires (fichiers de configuration, build script, script de la base de donnes, etc) dans le repository. On lutiliserait donc comme un filet de scurit afin de sassurer que le logiciel rpond e toutes les exigences et fonctionne comme il devrait. cf. [Duvall 2007, p. 81] 5.2.11 Lancer des builds rapides

La base de lIC, ce sont les feedbacks, savoir o en est le processus dintgration, quel test a chou, si le programme rpond aux attentes, etc. Ces informations se doivent darriver lintress (dveloppeur, client, responsable qualit,) dans les plus brefs dlais. Le thme du paragraphe 5.2.8 (Faire en sorte que les builds chouent rapidement) est une des consquences de cette pratique : plus la dure du build est courte, plus le feedback est rapide. Paul M. Duvall diffrencie le concept dvolutivit et celui de performance dans le cadre dun build. Lvolutivit du build indique quel point le systme du build est capable de grer laugmentation du nombre de codes quil intgre et analyse. La performance du build se rfre la dure du build. [Duvall 2007, p. 87] Il prcise que le systme dIC devrait tre capable de grer une augmentation du code sans grandes dgradations sur les performances. Il dcrit galement un processus en 4 points permettant de rduire au maximum la dure du build.

1. Rassembler les donnes du build Une liste de donnes qui peuvent tre pertinentes pour lamlioration de la dure du build est collecte. Paul M. Duvall en dresse une liste qui parat exhaustive :

5 Outils et automatismes adopter pour une IC idale

34

Temps de compilation, nombre de lignes de code, nombre et types dinspections, gnration du temps dassemblage moyen, temps dexcution des tests, ratio entre les builds russis et rats, temps dinspection, temps de dploiement, temps de rebuild de la base de donnes, ressources et utilisation de la machine ddie au build dintgration, chargement du systme de versionnement. cf. [Duvall 2007, p. 88] 2. Analyser les donnes du build On analysera ces donnes en fonction des techniques damlioration de la Figure 5-3, ainsi que des 3 critres voqus (volutivit, performance et difficult dimplmentation). 3. Choisir et appliquer les amliorations On choisira les amliorations spcifiques en fonction de la stratgie voulue, des moyens disposition et des ressources humaines disponibles. La Figure 5-3 donne une bonne ide des tenants et aboutissants du choix du dveloppeur.

Techniques damlioration

Priorit Evolutivit Performance Difficult

Utiliser une machine ddie pour les builds dintgration Augmenter les capacits physiques de la machine ddie au build dintgration

Amliorer les tests de performance

Garder une ligne pour le build dintgration


Optimiser linfrastructure

Optimiser le processus du build

5 Outils et automatismes adopter pour une IC idale


Faire les builds des composants du systme sparment Amliorer les performances de linspection du programme Faire des builds dintgration distribus 9 7

35

Lgende : impact sur lvolutivit, la performance et la difficult : et gale

haute

basse

Figure 5-3 : Tableau indiquant les amliorations possibles et ses consquences (lvolutivit, la performance et les difficults qui en rsultent), reprise du graphique de [Duvall 2007, p. 90]

4. Rvaluer et rpter si ncessaire Tout est dans le titre, il sagit de voir si les changements oprs correspondent aux objectifs fixs. 5.2.12 Refactorer les builds pour optimiser le processus

Paul M. Duvall propose 5 tapes pour optimiser le processus. cf. [Duvall 2007, p. 94]

1. Examiner linfrastructure On parle ici uniquement du matriel ou de sa configuration: d'un serveur inadapt, des performances du rseau, de systmes disperss gographiquement qui ralentissent le processus du build, etc. L'ide est donc de rechercher et amliorer si ncessaire les composants techniques qui gnrent le build. 2. Optimiser le processus du build Si le temps de compilation des fichiers est trop important, on peut parer ce problme en choisissant un build incrmental qui ne compilera que les fichiers qui ont t modifis depuis le dernier build. 3. Faire un build pour chaque composant du systme

5 Outils et automatismes adopter pour une IC idale (Donc le sparer en sous-systmes)

36

Le seul point dcisif pour que ces sous-systmes soient oprationnels, c'est qu'un soussystme matre soit dsign afin que chaque changement dans un sous-systme dpendant engendre un build complet. 4. Amliorer la performance de l'inspection du logiciel Faire en sorte que les informations recherches soient les plus pertinentes possibles. Plus on est concis dans le choix des valeurs qui nous intressent, plus l'inspection sera optimise. 5. Appliquer des builds d'intgration distribus Mthode qui ralentit plus qu'elle n'apporte des rsultats. On peut nanmoins l'utiliser dans le cas o toutes les solutions prcdentes n'ont pas apport satisfaction.

6 Les outils de dveloppement

37

Les outils de dveloppement

Nayant pas eu loccasion de tester tous ces diffrents outils de dveloppement, ils vous seront prsents selon certains critres fonctionnels prsents sur les pages Web des diffrentes firmes ayant dveloppes ces logiciels, et non sur des critres subjectifs comme lergonomie ou la facilit de prise en main. 6.1 Le serveur d'IC

Un serveur dIC pertinent est un serveur qui doit possder un minimum de fonctionnalits essentielles (lexcution du build , lintgration du contrle du versionnement, le feedback, la lablisation du build ) et plusieurs fonctionnalits qui lui permettent de se dmarquer de ses concurrents (la gestion des dpendances interprojets, linterface, la scurit, etc.). Dans les serveurs qui rpondent aux exigences principales et qui fournissent mme dautres prestations, on sintressera aux deux principaux serveurs disponibles sur le march, dont fait parti celui qui sera utilis dans la partie pratique du travail: AnthillPro et CruiseControl (.NET). Une matrice des diffrentes possibilits de chacune de ces deux ditions est disponible sur le site du dveloppeur de CruiseControl [ThoughtWorks 2009], datant du 15 avril 2010. Ne cherchant pas tre exhaustif mais simplement comparer ces deux serveurs, plus de 20 autres serveurs sont galement disponibles dans cette matrice la page Web mentionne dans la bibliographie. 6.1.1 AnthillPro

Distribu par Urbancode et utilisant la plateforme Java, cest un produit commercial qui dispose dun grand nombre de fonctionnalits. Autrefois, Urbancode proposait un logiciel libre sappelant Anthill OS. Le succs aidant, ils ont dcid de dvelopper le concept avec des amliorations importantes comme une configuration beaucoup plus flexible, la possibilit dutiliser diffrents versions de JDK (Java Development Kit) pour le build de projets diffrents, un support plus robuste pour les dpendances du projet ou la possibilit de lancer le build de nimporte quelle version antrieure. cf. [CM Crossroad 2009] Pour certains, les amliorations les plus significatives restent lauthentification et les paramtres dautorisation [Duvall 2007, p. 264] qui permettent aux administrateurs de grer les accs en matire de visualisation ou les options de configuration.

6 Les outils de dveloppement 6.1.2 CruiseControl .NET

38

Distribu par ThoughtWorks et utilisant, elle, la plateforme Microsoft .NET, CruiseControl.NET (CCNET) est le petit frre du doyen des serveurs dIC (CruiseControl, pour la plateforme Java). Cest un logiciel libre (cest--dire tlchargeable gratuitement sur le site Web du distributeur [SourceForge 2010, lien 1] ). Lun des grands avantages est la quantit de support et de documentation s disponibles pour sa mise en place qui compense le fait que la configuration est essentiellement manuelle dans un fichier XML, et qui la rend souvent peu intuitive pour le profane. De nombreux add-on permettent de faciliter la prise en main. On pourra citer le programme CCNetConfig qui permet une criture plus intuitive du fichier de configuration ou CCTray qui offre une meilleure visualisation des rsultats du build. Le WebDashboard peut galement tre install afin dinteragir avec le serveur via son navigateur WEB. 6.2 6.2.1 Les Builds scripts (N)Ant

Disponible depuis 2001, NAnt (pour Not Ant) est un programme permettant lautomatisation de la compilation du code-source .NET. Cest ce programme qui va tre utilis pour ce projet. On cherchera, via ce logiciel, optimiser et assouplir lintgration en vitant de devoir passer la compilation par une ligne de commande, le but tant dunifier le mode de compilation et dactions quon effectuera sur les sources, tout en intgrant XML. En plus de soccuper de la compilation, NAnt peut effectuer de nombreuses tches, parmi lesquelles: Compilation de sources en C, C++, C#, J#, Visual Basic.NET, et Jscript.NET Lancement des tests unitaires NUnit Manipulation de rpertoires ou de fichiers Accs en lecture/criture dans la base de registre Accs CVS (contrle de versionnement), ...

6 Les outils de dveloppement

39

NAnt possde de nombreux avantages en comparaison dautres logiciels correspondant. On citera dj le fait que NAnt est multi-plateformes, cest--dire quil est oprationnel aussi bien sur Linux, MacOs ou Windows. Dailleurs aujourdhui, la plupart des outils OpenSources en .NET sont distribus avec un script NAnt. Toutes les informations complmentaires ainsi que les liens de tlchargement sont sur la page WEB du dveloppeur [SourceForge 2010, lien 2]. 6.2.2 Maven

Apache Maven [Maven, 2010] est un outil logiciel libre pour la gestion et l'automatisation de production des projets logiciels Java. [Wikipedia 2010, lien 5] Il est considr comme bien plus simple configurer que Ant (la version Java de NAnt) : lcriture et la modification des scripts de Ant sont souvent fastidieuses. De plus, si les besoins divergent ou simplement la structure du projet diffre, le script Ant nest plus directement rutilisable et ncessite des retouches. En ce sens-l, la standardisation est nettement plus aise sur Maven. Il n'est dailleurs plus question de crer un fichier XML dcrivant prcisment les tches que l'on doit excuter pour construire son projet : Maven propose de dcrire son projet, il s'adapte alors cette description pour le construire. [Dveloppez.com, 2009] Finalement, Maven est plus flexible que Ant puisquil donne la possibilit ses utilisateurs de crer leurs propres plugins, contrairement au trs statique Ant. Maven utilise un paradigme connu sous le nom de Project Object Model (POM) afin de dcrire un projet logiciel, ses dpendances avec des modules externes et l'ordre suivre pour sa production. Il est livr avec un grand nombre de tches prdfinies, comme la compilation de code Java ou encore sa modularisation. [Wikipedia 2010, lien 5] 6.3 6.3.1 Le systme de contrle de versionnement Subversion

Subversion est un systme de contrle de versionnement (cf. Chapitre 10 pour le glossaire) ax client-serveur (Subversion tant le serveur) qui permet un grand nombre de dveloppeurs de travailler sur un mme projet. Particulirement apprci pour les projets OpenSource , il fonctionne en sappuyant sur une base centralise hberge sur le serveur qui contient la totalit des ressources (diffrentes versions, noms

6 Les outils de dveloppement

40

de lauteur du changement, dates de mises jour, etc.). Cette base centralise est aussi appele repository . Jusquici, cette dfinition du programme pourrait tre celle de CVS (Concurrent Versions System). En ralit, Subversion sappuie sur le mme principe de fonctionnement en maintenant la plupart des conventions de travail de CVS, y compris une grande partie de lensemble des commandes. Par contre, les amliorations sont notables par rapport son prdcesseur. Subversion propose, contrairement CVS, des commits atomiques, ce qui vite de se retrouver dans un tat contradictoire si une opration sur le repository est interrompue en plein milieu. Ceci est permis en utilisant de faon sous-jacente une base de donnes capable de grer les transactions atomiques (p.ex. Berkeley DB) [Wikipedia 2010, lien 4] . On parlera aussi du dplacement ou le renommage des fichiers/rpertoires qui sont possibles sur Subversion sans mme en perdre lhistorique. Enfin on peut dfinir les permissions daccs sur les diffrentes parties du repository grce au protocole WebDAV, tandis que CVS ne le peut que de faon limite. Le site suivant [Better SCM 2010] propose un comparatif quasi exhaustif des diffrents logiciels de contrle de versionnement et est mis jour de faon rgulire (au 18 mai 2010 au moment dcrire ces lignes). Il apparat que Subversion est un logiciel trs comptitif sur ce march. 6.3.2 TortoiseSVN

Un logiciel de contrle de versionnement centralis implique linteraction serveurclient. Subversion tant le serveur, TortoiseSVN est son client open-source qui va grer les fichiers et les rpertoires travers le temps. Outre un accs trs intuitif Subversion au travers du menu contextuel de lexplorateur, TortoiseSVN y ajoute galement son propre menu. On repre galement trs rapidement le statut de la copie de travail grce de petites icnes de recouvrement. Dans la mesure o ce nest pas une intgration pour un IDE spcifique tel que Visual Studio ou Eclipse, il est possible de lutiliser avec tous les outils de dveloppement disponibles. [TortoiseSVN 2010] et [Optus.net 2007] 6.4 Les Feedbacks

Cest un fait que la qualit de la documentation technique destine aux dveloppeurs responsables de la maintenance de lapplication influe grandement sur la prennit dun projet de dveloppement.

6 Les outils de dveloppement 6.4.1 Doxygen

41

Doxygen ou littralement gnrateur de documentations (DOCuments GENerator) est un logiciel permettant de crer des documentations techniques pour notamment le C, C++, C# ou Java, ce dans diffrents formats (HTML, PDF, LaTeX, RTF, PostScript et prochainement en XML). En extrayant linformation partir du code source, il permet de systmatiser le comportement du dveloppeur afin quil prenne des habitudes allant dans ce sens. Le site officiel [Doxygen 2009] , rdig par Dimitri van Heesch, crateur de Doxygen, donne une liste des caractristiques principales de ce logiciel. Parmi elles, on pourrait citer le fait que Doxygen permet linsertion des dfinitions de fonctions, de membres ou de classes dans la documentation. Il permet aussi de dtecter automatiquement les fonctions prives, publiques ou protges, de mme que Qt, une bibliothque logicielle oriente objet et dveloppe en C++. Tout a t mis en place pour faciliter lutilisation et la lecture, comme les fragments de code source qui sont mis en vidence de faon syntaxique. [Doxygen 2009] , Doxygen ne sera pas utiliser pour la partie pratique de ce travail, cette prsentation tant simplement l pour dfinir les outils disponibles dans le cadre dune pratique de dveloppement informatique idal , dans le sens o le temps investi la mise en place sera rentabilis sur le long terme.

7 Lavenir de lIC et ses alternatives

42

Lavenir de lIC et ses alternatives

L'intgration continue est un terme nouveau. Son principe repose cependant sur certaines mthodologies qui, elles, sont appliques depuis plusieurs annes dj. On sait que l'intgration est un problme qui devrait persister dans les annes venir. Malgr toutes les amliorations qu'on peut imaginer, l'objectif terme restera donc toujours le mme : faire de l'intgration un non-vnement. Nous allons voir dans ce chapitre lavenir que peut nous rserver lIC et les possibles alternatives disposition. 7.1 Avenir de lIC

Nous pouvons dj percevoir les diffrents virages que lIC va entreprendre lavenir, certains dveloppeurs nayant pas attendu la fin de ce travail pour crer des logiciels encore plus performants et mieux agencs. Il est plus ais de se baser sur un logiciel payant pour apprcier lvolution du secteur. Prenons, par exemple, le cas de TeamCity : depuis juin 2009 et sa version 4.5, il propose de changer le scnario codage-commit-vrification en codage-vrification-commit (cf. Figure 7-1 : Codage-Vrification-Commit selon TeamCity [TeamCity 2009] le commit se faisant automatiquement quand la vrification est effectue. On vite ainsi de se retrouver avec un build ne fonctionnant pas dans le logiciel de contrle de versionnement.

Figure 7-1 : Codage-Vrification-Commit selon TeamCity [TeamCity 2009]

7 Lavenir de lIC et ses alternatives

43

Mme si la plupart des versions sorties jusque-l amliorent principalement lergonomie, le support, la compatibilit dautres logiciels (ou langage), la configurabilit, etc., aucun changement majeur na vraiment t ralis depuis, du moins dun point de vue architectural. Paul M. Duvall nous donne dans son livre [Duvall 2007, p. 224] deux axes principaux pour optimiser la pratique de lIC dans le futur : se concentrer sur la prvention des builds endommags la rapidit dexcution des builds

Concernant ce dernier point, il sagit moins de prouesses technologiques que de lassiduit des dveloppeurs dont il est question. Les diffrents chapitres de ce travail ont dj mis en exergue les dmarches mettre en uvre pour optimiser la vitesse dexcution du build pour des feedbacks plus rapides. Pour ce qui est de la prvention, Duvall propose un intressant commit deux phases. En rsum, le dveloppeur commit son travail qui intgre une queue . Il ne sera intgr que sil nentre pas en conflit avec un autre commit. Si lintgration se passe avec succs, il sera ensuite plac dans le repository. (cf Figure 7-2 : Commit 2 phases, [Duvall 2007, p. 224] ci-dessous)

Figure 7-2 : Commit 2 phases, [Duvall 2007, p. 224]

7 Lavenir de lIC et ses alternatives

44

Cette pratique laisse cependant nombres de dveloppeurs perplexes, lassimilant celle dj bien ancre dans le monde de la programmation, la branch per task (littralement : une branche par tche), dont Brad Appleton a t un des prcurseurs [Appleton 1998]. Ceux-ci prtendent que les avantages quapporteraient cette solution sont prcisment les mmes que ceux dun systme avec un bon branching . Le problme de largumentation de Paul M. Duvall est quil se focalise sur une programmation globale , cest--dire quil ny a quune branch principale pour toutes les tches (ou presque). cf. [Codicesoftware, 2008] Le branching , dans un contrle de versionnement, est simplement la duplication dun code source, dun fichier, etc. de faon ce que les modifications prennent effet en parallle parmi ces deux branches. Ce branching peut prendre cinq formes diffrentes selon les besoins : physique, fonctionnel, environnemental, organisationnel et procdural. La branch per task excute quant elle chaque tche sur sa propre branche dactivit. Cette approche permet de dvelopper paralllement des projets de large envergure impliquant de nombreux acteurs. Elle permet aussi lisolation des changements, comme la rsolution des bugs ou lintgration des versions, sans dstabiliser le code, pour ensuite resynchroniser ces changements aprs tous les tests. cf. [Wikipedia 2010, lien 2] Il est certain quune paralllisation standardise des diffrents tests, couple un environnement plus complexe permettrait d'exploiter au maximum la croissance de la performance des machines qui s'amliorent une vitesse quasiment exponentielle (ce, mme si les logiciels voient eux-aussi leur complexit augmenter).

Where do you see CI going in the future?

I think there is much more we can make "automatic for the people". I foresee future development shops to look like a NASA or television control room including real-time monitoring of the software under development, and if anything goes beyond our identified thresholds, we are notified and can take immediate action. I see the future of CI increasing the efficiency and quality of software we develop for our users. Interview avec Paul Duvall, [Stelligent 2008]

7 Lavenir de lIC et ses alternatives 7.2 Les alternatives

45

Git [Git 2010] est un SCV (systme de contrle de versionnement) dvelopp initialement par Linus Torvalds (le crateur du systme dexploitation libre Linux) et sorti en 2005. Lune de ses caractristiques principales est que, contrairement la plupart de ses concurrents qui empruntent un modle centralis bas sur un seul et mme serveur, Git est compltement dcentralis. Cette particularit implique que chaque collaborateur dispose dune version complte du dpt distant (et non plus de la dernire version uniquement) sur son ordinateur, appel alors dpt local . Une connexion internet nest donc plus indispensable pour continuer travailler. [maximebornemann.com 2010] Git possde galement de nombreux avantages, tels que : Cration de branches : on peut fusionner ou crer des branches trs facilement Transaction atomique : lorsque vous commitez des fichiers modifis, Git s'assure qu'ils seront tous pris en compte. Si ce n'est pas le cas, le processus s'annule, permettant ainsi votre dpt d'viter la corruption. La Staging Area (voir chapitre 5.1.2) : quand la plupart des VCS possdent deux tats pour leurs fichiers (commits ou modifis), Git rajoute un tat transitoire (staged). A la place de commiter vos fichiers une fois une modification effectue, Git place un snapshot (qui fait rfrence la copie actuelle de l'tat d'un systme [Wikipedia 2010, lien 6] ) dans une zone intermdiaire (staging area, ou index). Vous pouvez donc continuer modifier vos fichiers sans vous proccuper d'un prcdent commit. cf [Fedora 2010] Maintenant que les spcificits de Git ont t explicites, la question serait : en quoi ce logiciel pourrait tre une alternative l'IC? Tout simplement parce qu'il permet de mettre en place une sorte d'IC sans serveur distant, donc compltement gratuit. Il suffirait de dupliquer (Git Clone) le code-source du rpertoire de travail vers un second rpertoire depuis lequel le build serait lanc, et, en cas de succs, le commit serait effectu. De plus, avec Git Clone, Git copie les fichiers via des liens qui permettront ensuite de mettre jour le rpertoire trs rapidement. Pour la resynchronisation du rpertoire de travail Git Pull permet au rpertoire courant de contenir exactement les mmes fichiers et les mmes commit que ceux qui ont t pousss sur le repository partag, tout a grce au hash des fichiers. [Javabien.net 2010]

7 Lavenir de lIC et ses alternatives

46

Cette solution telle qu'elle est prsente est vritablement prometteuse, puisquelle nimplique aucune maintenance, une excution via une seule commande et plus d'erreur dans le repository, donc tous les avantages d'un systme d'IC, le serveur en moins. Il faudrait nanmoins la tester pour identifier les probables dsavantages qu'elle implique.

8 Environnements de dveloppement de la BSU

47

Environnements de dveloppement de la BSU

La BSU (Brsenspiel der Schweizer Universitten) est une association dtudiants de lUniversit de Fribourg qui propose chaque anne une simulation de jeu boursier depuis 1992. Si le concept sduit en accueillant de plus en plus dtudiants annes aprs annes (ldition 2009 tant une exception), il faut admettre que le programme dadministration du jeu ainsi que larchitecture de ses bases de donnes nont pas beaucoup volu ces 10 dernires annes. Lobjectif des annes venir pour la Team IT (quipe charge de linformatique dans lorganisation de la BSU) sera de faire avancer le jeu en proposant une nouvelle architecture, lintgration de logiciels plus performants ou un nouveau processus de configuration du jeu, ceci afin damliorer les performances gnrales du jeu. Cest sur cette dernire proposition que se concentrera ce travail. Pour donner une ide des performances accrues qui dcouleraient de la mise en place de lIC pour un futur projet de dveloppement, il fallait un projet informatique en cours de dveloppement voir termin. Cest donc sur le travail de Master dHlne Martenet [Martenet 2009] que vont tre concentres toutes les tapes de cette partie pratique. 8.1 Situation sans IC

Actuellement les projets informatiques ne sont grs que par un simple logiciel de contrle de versionnement (Subversion sur le serveur mis disposition par lUniversit, et TortoiseSVN [TortoiseSVN, 2010] sur les ordinateurs de chaque dveloppeur) (cf. Figure 8-1 : Situation de lenvironnement de dveloppement de la BSU) et un logiciel de travail collaboratif (Groove, issu de Microsoft Office, ou plus rcemment, Wuala [Wuala, 2010] qui permet un stockage en ligne et dvelopp par LaCie) afin dchanger les informations sur la programmation, les dlais et autres dates de runion. Cette configuration pourrait suffire pour le dveloppement dun petit projet concernant 1 ou 2 personnes, mais si les membres de lquipe planchent ensemble sur un programme plus complexe, il serait judicieux de revoir lenvironnement.

8 Environnements de dveloppement de la BSU

48

Figure 8-1 : Situation de lenvironnement de dveloppement de la BSU avant la mise en place dun systme dIC 8.2 Situation aprs mise en place de lIC

La mise en place dune architecture diffrente pour lIC destine optimiser la qualit et le temps de production final dun projet pour le BSU a t lobjet de ce travail. La Figure 8-2 donne un bon aperu de ce quoi larchitecture ressemble.

8 Environnements de dveloppement de la BSU

49

Figure 8-2 : Mise en place de lIC pour la BSU

CruiseControl.NET (le serveur dIC) ainsi que TortoiseSVN sont installs sur le serveur BSU-IC. Les dveloppeurs auront galement chacun TortoiseSVN install sur leur poste de travail et feront un commit rgulier de leur travail. Subversion ne sera donc pas install sur la mme machine que CC.NET (ce qui aurait pu tre fait, vu que tous les pr-requis avaient t mis en place dans cette optique). Le choix dun systme de contrle bas sur un simple test de modification du fichier se justifie par le fait que ladministration pour un systme Serveur-Client comme Subversion est assez complexe mettre en uvre au niveau des autorisations daccs (pare-feu), et vu que lUniversit met disposition un serveur ddi SVN [DIUF-SVN 2010] , le choix sest port sur une autre solution. Linformation ncessaire au fichier .build (le Build Script qui ordonne toutes les tches, lanc par CC.NET et excut par NAnt) sera donc le chemin daccs au dossier racine du projet, dossier gr par TortoiseSVN. Le but tait de mettre en place un systme dIC similaire celui quune quipe de dveloppement pourrait utiliser. Il tait donc important que les updates de TortoiseSVN se fassent de manire automatique afin dviter de devoir se connecter sur le serveur BSU-IC pour le faire manuellement. Dans cette optique, un petit fichier .BAT sera excut par NAnt pour des updates automatique et ainsi vrifier si un fichier a t rajout Subversion sur le serveur DIUF-SVN, et le cas chant, le tlcharger via

8 Environnements de dveloppement de la BSU

50

TortoiseSVN afin que le nouveau build se fasse. Lintgration aura alors lieu ainsi que le mcanisme de feedback qui informera les dveloppeurs de lissu du build.

Il a t question dans les chapitres 2.3 et 2.4 des avantages et dsavantages de la mise en place dun systme dIC dans une quipe de dveloppement. Ces avantages se retrouvent bien sr pour des projets un peu moins ambitieux que ceux dune quipe de programmation professionnelle. En prenant le cas de la BSU, qui compte 3 4 dveloppeurs dans ses rangs, ses projets nont encore jamais inclus plus de 2 intervenants en mme temps (pour ce qui est de ces deux dernires annes du moins). Un des principaux atouts de lIC tant quil permet de limiter les problmes que peut poser linteraction du travail, il est certain que la BSU nexploitera pas tout le potentiel damlioration que peut apporter un systme dIC. La mise en place dun tel systme aide nanmoins mieux visualiser son propre travail et celui des autres, assumer ses erreurs et connatre avec prcision lavance du projet. Enfin, ces changements seront prcieux lorsquil sagira de rendre la version finale du programme. 8.3 Lanalyse Analyse SWOT SWOT (de l'anglais Strengths (forces), Weaknesses (faiblesses),

Opportunities (opportunits), Threats (menaces)), ou MOFF (Menace, Opportunits, Forces et Faiblesses) pour les francophiles, est un outil de stratgie dentreprise couramment utilis lorsquil est ncessaire danalyser une situation prsente dune manire structure. [Atkinson 1998]

Figure 8-3 : Cheminement de lanalyse SWOT [GroupeRessources.com 2010]

8 Environnements de dveloppement de la BSU

51

SWOT donne accs lidentification des forces et des faiblesses du projet en regard des opportunits et des menaces de lenvironnement externe. La mthode vise identifier les stratgies maximisant le potentiel de forces et dopportunits, tout en minimisant limpact des faiblesses et des menaces. Elle constitue ainsi une charnire entre analyse et diagnostique. [COTA 2006]

Voici les 4 plans de la matrice SWOT et leurs significations dans ce contexte : Forces : Il sagit des avantages comptitifs que lassociation BSU peut acqurir grce la mise en place du systme dIC, ceci en regard de lancien environnement de dveloppement. Faiblesses : Il sagit des dsavantages la mise en place du systme dIC auxquels lassociation BSU devra faire face, ceci en regard de lancien environnement de dveloppement. Opportunits : Il sagit du domaine d'action dans lequel la BSU peut esprer jouir d'un avantage diffrenciant grce lIC (par rapport lancienne solution). Menaces : Il sagit des perturbations de l'environnement de la BSU qui ont des chances de se raliser suite la mise en place de la plateforme dIC.

Forces Rduit les risques

Grce aux tests et aux inspections dclenchs ds le commit du fichier dans le repository, on rduit les risques dun programme corrompu. Meilleure visualisation

Grce aux feedbacks immdiats aprs le build, les dveloppeurs (et autres intresss) ont une visualisation parfaite de ltat du projet ainsi que de son avancement. Gain de temps en gnrant un logiciel dployable (viter lIntegration Hell)

Le gain de temps sera surtout perceptible en fin de projet. Les dveloppeurs plus aguerris, ayant dj eu affaire une intgration tardive, pourront en tmoigner : repousser lchance du build amne souvent de mauvaises surprises.

8 Environnements de dveloppement de la BSU Obtenir un code fiable

52

De nombreux outils dvelopps pour lIC permettent dviter la duplication du code, dappliquer un standard dans la convention du code, etc. et donc doptimiser la fiabilit du code (il sagit en gnral de paramtrer dans le logiciel, les critres qui semblent importants pour le dveloppeur). Meilleure qualit

Comme dfinit dans le glossaire au chapitre 10 , la qualit est en fait la pondration de spcificits telles que lextensibilit, la scurit, la performance, la capacit tre maintenu et la lisibilit. LIC mise en place pour la BSU permettra dobtenir un programme de meilleure qualit.

Faiblesses Script NAnt peu intuitif

NAnt est un programme difficile intgrer. Son utilisation dans un projet utilisant des technologies du Framework 3.5 impliquent des problmes de compatibilit foison. De plus, il est assez peu intuitif et sa prise en main prendra logiquement plus de temps pour lapprivoiser compltement. Mise en place rbarbative

La mise en place dun systme dIC pour un projet demande de la patience pour les profanes. Peu de fichiers sont dvelopper mais il faut quand mme du temps pour se familiariser avec ces nouveaux outils. La migration (voir point suivant) est galement assez fastidieuse, il serait donc judicieux de commencer son projet directement avec lIC, et non pas de lintgrer par la suite. Migration

La coordination quimplique le passage dun gros projet sur une plateforme dIC est souvent dmotivante, dautant plus que ces projets sont souvent rpartis dans de nombreux environnement de dveloppement (voir le chapitre 2.4 sur les dsavantages de lIC).

8 Environnements de dveloppement de la BSU Beaucoup plus de rgles de codage

53

Auparavant dans la BSU, aucune rgle ne rgissait le dveloppement dun code. Avec lIC, pour que CC.NET lance sa routine de tests (par exemple), il faut en crire ! Cest une lapalissade que de le mentionner, mais beaucoup de rgles sont indispensables pour profiter des avantages que procurent lIC. Mme si on peut considrer a comme une faiblesse dans un premier temps, il est certain que ces habitudes de dveloppement, aussi contraignantes soient-elles, doivent tre perues comme une force dans le futur. Lenteur dexcution du build

Il sagit dun problme rcurrent pour les builds de projets importants. De nombreuses techniques pour optimiser le temps du build sont proposes au chapitre 5.2 (dans le cas o celui-ci sterniserait). En ce qui concerne la BSU, le problme pourrait tre dautant plus flagrant que le build implique dans son processus un check-out de TortoiseSVN (le client de Subversion).

Opportunits Motivation supplmentaire

La mise en place dun serveur dIC ainsi quun serveur ddi au build permettra certainement un regain de motivation quant la cration de nouveaux logiciels pour lassociation BSU. La nouvelle infrastructure ainsi que le guide dutilisation permettront de mieux prparer le terrain pour les dveloppeurs de la BSU. Dcouverte dun nouveau concept

Ce nouvel outil de travail permettra aux dveloppeurs dlargir le spectre de leurs expriences en matire de dveloppement. Confiance des dveloppeurs

Peur de commiter un code corrompu, ou, au contraire, peur de rcuprer un code corrompu dvelopp par un collgue ? Ce problme nexiste plus avec le serveur dIC de la BSU. Cet tat de fait contribue donner confiance aux dveloppeurs et conforter lesprit dquipe. Ceux-l nhsiteront plus apporter leur contribution au projet.

8 Environnements de dveloppement de la BSU Acqurir de bonnes habitudes de dveloppement

54

Chacun sa manire de coder, mais le dveloppement en quipe implique quelques rgles de bonne conduite , de telle sorte quun programmeur puisse reprendre le travail de son collgue sans avoir lui demander des explications. Le dveloppement via un systme dIC incite les dveloppeurs acqurir de nouveaux rflexes en matire de dveloppement.

Menaces Aversion au changement

Changer dhabitude de programmation nest pas chose aise. Il existe de nombreux dveloppeurs ayant test lIC qui ont prfr revenir une programmation traditionnelle . Problmes de compatibilit au Framework 3.5

Les programmes ncessaires au bon fonctionnement de lIC tant dj installs, cette menace ne devrait pas vraiment en tre une. Nanmoins, plusieurs outils nont pas t intgrs dans larchitecture dIC actuelle. Chaque nouvelle installation rvlant son lot de surprise, il faudrait ds lors sattendre des problmes ce niveau. De m me, linstallation automatique des Updates de Windows implique le chargement des Frameworks les plus rcents (le numro 4 est dj disponible). Ceux-ci pourraient nouveau engendrer des problmes de compatibilit. Choix technologiques de lquipe IT de la BSU

CruiseControl.NET est un outil ddi au langage .NET. Ce langage ntant pas des plus utiliss dans le milieu estudiantin de lUniversit de Fribourg (aucun cours ne traite de ce langage), il est probable que Java (ou un autre) lui soit prfr. Il faudrait alors remettre en place un nouveau systme dIC avec des programmes diffrents (CruiseControl et Ant par exemple). Nouveaux systmes simplifis

Lavenir de lIC est dvelopp au chapitre 7.1. Il y est propos certaines voies damlioration quont entrepris (ou pourraient entreprendre) les dveloppeurs. Lune delle, Git, est particulirement intressante et pourrait peut -tre bien suppler le systme mis en place pour la BSU dans un avenir proche.

8 Environnements de dveloppement de la BSU Abandon du concept

55

Existant depuis 1994, la BSU est une petite association avec peu de dveloppeurs. Le programme PMS tant la base du jeu na, par exemple, pas t retouch depuis plus de 10 ans. On pourrait simaginer que lvolution de lIT (Information Technology) demeure au statu quo avec quelques volutions anecdotiques, auquel cas le concept dIC ne serait videmment plus dactualit. Nanmoins, les projets informatiques planifis pour ces prochaines annes laissent prsager des changements importants. LIC de la BSU aura alors de beaux jours devant elle.

Lanalyse SWOT du systme dIC pour la BSU permet de rendre compte des avantages et dsavantages inhrents son installation. Il est par contre trs difficile de juger quelle sera lvolution de son environnement. Toutefois cette analyse, bien quassez subjective, permettra sans doute de mieux cibler les diffrents scnarios auxquels la plateforme dIC de la BSU pourrait faire face.

9 Conclusion

56

Conclusion

Nous avons pu constater que malgr tous les outils mis disposition pour raliser une IC efficace, cela reste un concept ou plutt une attitude adopter. Toutes les tapes peuvent parfaitement tre entreprise de faon manuelle et/ou avec une architecture diffrente afin de se passer des outils mentionns au paragraphe 6 . Pour tre cohrent avec cette affirmation, on peut simplement considrer une autre faon de percevoir CruiseControl .NET : nous lavons dcrit comme un serveur dintgration, ce quil est, maintenant un ordinateur externe qui viendrait rcuprer la dernire version du code sur le repository et sassurerait que ce code soit viable pour le build aurait le mme rsultat. Cette machine dintgration ddie possde les mmes avantages que CruiseControl, lautomatisation en moins. Lobjectif de cette digression est de mettre en avant le rle de lIC. Son origine ne provient que dune seule et unique rgle des projets XP et Agile : le code-source du repository doit passer tous les tests, et le build doit se faire . A partir de l, on comprend que tous les moyens sont bons pour arriver ses fins, sachant que toute sa structure est parfaitement modulable. Tous les outils voqus dans ce travail sont donc utiles mais pas indispensable, limportant tant que lquipe de dveloppement prennent de nouvelles habitudes de programmation. De plus, la quantit/qualit de linformation ainsi que des programmes ddis lIC se sont grandement dvelopps durant lcriture de ce travail, dautant que celui-ci a t rdig sur une priode plus importante que prvue. Ceci constitue le meilleur exemple des efforts mis en place par les socits informatiques afin de proposer des outils dIC optimaux. Concernant la BSU, lobjectif de chaque membre actif de cette association est dacqurir un peu dexprience de la vie professionnelle et dappliquer ses connaissances sur un projet commun : pour des tudiants en informatique, le fait de disposer dun outil collaboratif aussi performant permettra sans doute doser se lancer dans de nouveaux projets, en quipe, dacqurir de nouveaux rflexes de programmation (Agile), de ne plus apprhender de retrouver un logiciel bugg par un de ses collgue ou au contraire de commiter son travail sur Subversion, et surtout davoir une vision globale du projet et de son avance.

9 Conclusion

57

Dun point de vue plus personnel, lcriture de ce travail ma permis de connatre un concept qui mtait encore inconnu et qui me permettra sans aucun doute de mieux apprhender les dangers de lintgration durant ma vie professionnelle. Les diffrents langages ou les configurations (quelles soient systme ou lies aux programmes) mont galement permis de percevoir au mieux toutes les relations quexigent lcriture dun programme grande chelle : mtant toujours born des petites applications ne ncessitant en aucune faon laide de tierces personnes, il tait essentiel de comprendre limportance des outils de travail collaboratif.

10 Glossaire et Table dabrviation

58

10

Glossaire et Table dabrviation

Voici un petit rcapitulatif des termes et abrviations qui ont jalonn ce travail. 10.1 Glossaire Version Control Repository (ou Repository) / Version Control System Un SCV (systme de contrle de versionnement) est un lment indispensable pour la cration d'un logiciel. Il s'agit en fait d'un dossier commun dans lequel rsident tous les codes-source, le but tant de pouvoir y accder en un point central afin de pouvoir rcuprer la version la plus rcente du code, ou revenir dans le temps si une nouvelle version est corrompue. Les logiciels de contrle de versionnement (VCS, Version Control System) fonctionnent justement grce au concept de repository et donnent la possibilit une ou plusieurs ressources informatiques de stocker leurs donnes afin de les labliser et de pouvoir, par la suite, identifier et rcuprer toutes les versions intermdiaires des ressources. Le SCV soccupe donc des mises jour du code-source et conserve les diffrentes versions lors dun changement, la nouvelle version tant simplement incrmente de 1 (li au dveloppement linaire) par rapport la prcdente (rvision). Ce mme concept sera aussi utile (et utilis) lors des builds. De nombreux systmes permettant le contrle des versions (ou versionnement ) sont disponibles (comme Subversion ou TortoiseSVN). [Wikipedia 2010, lien 3] Automatis: On parle d'automatisation lorsque le processus est compltement automatis et ne requiert pas d'intervention d'un utilisateur. En anglais, on parle d'un processus headless ou hands-off . cf. [Duvall 2007, p. 27] Build: Il s'agit d'un ensemble d'activits dont l'objectif est de gnrer, tester, inspecter et dployer le logiciel. C'est donc bien plus qu'une simple compilation: on met le codesource en commun et on vrifie qu'il ragit bien comme une unit cohsive. cf. [Duvall 2007, p. 27] Environnement de dveloppement Il s'agit de l'environnement dans lequel le programme est crit. Le plus souvent on parle d'un IDE (Integrated Development Environment) comme Eclipse ou Visual Studio, mais

10 Glossaire et Table dabrviation

59

les librairies, les fichiers de configuration, les serveurs ou les builds scripts en font aussi partie. cf. [Duvall 2007, p. 28] Intgration C'est l'acte de combiner des parties de codes-source spares, pour dterminer comment elles fonctionnent comme un tout. cf. [Duvall 2007, p. 28] Inspection Il s'agit de l'analyse du code-source pour les attributs de la qualit interne. On considrera les aspects automatiques (analyses statiques et du temps d'excution) comme une inspection de logiciel. cf. [Duvall 2007, p. 28] JDK (Java Development Kit) Le Java Development Kit (JDK) est l'environnement dans lequel le code Java est compil pour tre transform en bytecode afin que la JVM (machine virtuelle de Java) puisse l'interprter. cf. [Java.Net 2010] Qualit La qualit est une valeur donne aux diffrentes spcificits du produit. Ce terme est trs subjectif et peut varier en fonction des priorits de chacun et de la pondration quon attribue ces spcificits. Parmi elles on trouve : lentretien, la scurit, les performances, lextensibilit, les tests oprs durant la conception du programme, etc. cf. [Duvall 2007, p. 28] Risque Le risque est la potentialit quune erreur survienne. On observera que la plupart des programmateurs les classent en fonction dun rapport entre leurs typologies (degrs de dangerosit ) et dune estimation de leur probabilit dapparition. On peut ainsi rduire les risques en suivant un schma basique : danalyse du risque, de rduction/prvention et de suivi. cf. [CNRS 2010]

10 Glossaire et Table dabrviation 10.2 Table dabrviation

60

Acronyme, sigle ou abrviation BD BSU CCNET Cf DBL DDL DML IC IDE IIS IT JVM SCV SVN SWOT URL XML XP VS

Signification Base de Donnes Brsenspiel der Schweizer Universitten CruiseControl .NET confer Data Base Administrator Data Definition Language Data Manipulation Language Intgration Continue Integrated Development Environment Internet Information Services Information Technology Java Virtual Machine Systme de contrle de versionnement Subversion Strengths Weaknesses Opportunities Threats Uniform Resource Locator Extensible Markup Language eXtreme Programming Visual Studio

11 Bibliographie

61

11

Bibliographie

[AnthillPro

2009],

Serveur

d'IC

payant,

http://www.anthillpro.com/blogs/, (consult

http://www.anthillpro.com/html/resources/build-pain-relief/notification.html le 28.05.2010)

[Appleton 1998], Brad Appleton, Stephen Berczuk, Ralph Cabrera, and Robert Orenstein, 1998: Streamed Lines: Branching Patterns for Parallel Software Development, http://www.cmcrossroads.com/bradapp/acme/branching/ (consult le 20.05.2010) [ASP.NET Forum 2005], Forum daide pour ASP.NET,

http://forums.asp.net/p/869604/869604.aspx (consult le 08.06.2010) [Atkinson 1998], Kim Atkinson, 1998: SWOT analysis: a tool for continuing professional development, International Journal of Therapy and Rehabilitation [Better SCM 2010] , Site de comparaisons de systme de contrle de versionnement, http://better-scm.berlios.de/comparison/comparison.html (consult le 09.06.2010) [Blog Dveloppeur 2009], Partage dinformations entre dveloppeurs, (consult le

http://blogs.developpeur.org/redo/archive/2004/08/16/2286.aspx 28.09.2009)

[BuildMeister 2009], Site qui propose une prsentation des outils pour le build, http://www.buildmeister.com/ (consult le 24.05.2009) [CFTL 2009], Comit franais des tests logiciels, dfinitions,

http://www.cftl.net/cms/files/Dokumente/frGlossaire%20des%20tests%20de%20logicie l%20-%20ISTQB.pdf (consult le 26.05.2009) [CM Crossroad 2009], Crossroads the Configuration Management Community, http://www.cmcrossroads.com/, http://www.cmcrossroads.com/cgi-

bin/cmwiki/view/CM/AnthillPro (consult le 20.05.2010) [CNRS 2010], Centre National (franais) de Recherches Scientifiques,

http://www.dsi.cnrs.fr/conduite-projet/phasedefinition/qualite/risques/basdefqual.htm (consult le 07.06.2010)

11 Bibliographie [CodeBetter 2009], Partage dinformations entre

62 dveloppeurs,

http://codebetter.com/blogs/jeffrey.palermo/archive/2007/11/28/upgrade-nant-for-usewith-vs2008-solutions-and-net-3-5.aspx (consult le 16.09.2009) [Codicesoftware, 2008], Site officiel de Codice Software, crateur de logiciels de dveloppement, http://codicesoftware.blogspot.com/2008/03/continuous-integration-

future.html (consult le 26.07.2009) [COTA 2006], Site dune ONG de droit belge : article sur lanalyse SWOT, http://www.cota.be/SPIP/IMG/pdf/Fiche_1A_GCP_SWOT.pdf (consult le 14.09.2010) [Crossroads 2004], Magazine informatique pour le management de la configuration, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83.6098&rep=rep1&type=pd f (consult le 26.05.2010) [Dveloppez.com 2009], Site daide aux dveloppeurs, (consult le

http://linsolas.developpez.com/articles/java/outils/builds/#LV-A-1 29.08.2010)

[Di-ENS-Labatut 2007], Pour les tests unitaires et la couverture des codes, http://www.di.ens.fr/~labatut/ED6/cours-6.pdf (consult le 20.05.2009) [DIUF 2010], Site du dpartement dinformatique de lUniversit de Fribourg, https://diuf.unifr.ch/wiki/Subversion (consult le 16.09.2009) [DIUF-SVN 2010], Serveur SVN de lUniversit de Fribourg, http://diuf-svn.unifr.ch (consult le 18.05.2010) [Doxygen 2009], Site officiel du gnrateur de documents,

http://www.stack.nl/~dimitri/doxygen/features.html (consult le 26.05.2010) [Duvall 2007], Paul M. Duvall, 2007: Continuous Integration, Improving Software Quality and Reducing Risk, 1st Edition. Addison-Wesley, Pearson Education 2007. [Duvall WS 2009], Support Internet du livre de Paul Duvall, http://integratebutton.com (consult le 20.05.2009) [Extreme Programming 2009], Site officiel sur lExtreme Programming,

http://www.extremeprogramming.org/ (consult le 20.05.2009) [Fedora 2010], Site de la communaut francophone de Fedora, systme dexploitation libre bas sur Linux, http://doc.fedora-

11 Bibliographie fr.org/wiki/Gestion_et_contr%C3%B4le_de_versions_avec_Git 13.09.2010) [Fowler 2008], Site official de Martin (consult

63 le

Fowler,

http://martinfowler.com/articles/continuousIntegration.html (citation p.2/12, consult le 29.05.2009) [Git 2010], Site officiel du logiciel Git, http://git-scm.com/ (consult le 08.09.2010) [GroupeRessources.com 2010], Site dune agence de placement, article sur lanalyse SWOT, 14.09.2010) [Java.Net 2010], Informations sur la technologie Java, https://jdk.dev.java.net/ (consult le 07.06.2010) [Javabien.net 2010], Blog concernant Java http://blog.javabien.net/tag/hudson/ (consult le 12.09.2010) et Agile, http://www.grouperessources.com/index.php?p=Offre2 (consult le

[Knoernschild 2008], Kirk Knoerschild, 2008: Continuous Integration: The Project Heartbeat, http://www.burtongroup.com/research/PublicDocument.aspx?cid=1500

(accs Client indispensable pour visualiser ce document, consult le 05.06.2009) [Larousse 2010], Dictionnaire Larousse en ligne,

http://www.larousse.fr/dictionnaires/francais/compiler (consult le 11.05.2010) [Martenet 2009], Hlne Martenet, 2009 : Analyse des exigences dun jeu boursier en ligne et implmentation dun prototype damlioration. Travail de Master, Universit de Fribourg. [Maven, 2010], Site officiel dinformation et de tlchargement du logiciel Maven, http://maven.apache.org/ (consult le 29.08.2010) [maximebornemann.com, 2010], Site/Blog sur les nouvelles technologies,

http://maximebornemann.com/introduction-au-controle-de-version-avec-git (consult le 08.09.2010) [MSDN 2010], Ressources Microsoft pour technologie .NET, le

http://msdn.microsoft.com/fr-fr/library/a99txfy5%28VS.80%29.aspx 11.05.2010)

(consult

11 Bibliographie

64

[NUnit 2010], Site officiel de tlchargement du logiciel NUnit, http://www.nunit.org/ (consult le 26.07.2010) [Optus.net 2007], Site proposant des tutoriaux, http://mirror.optus.net/sourceforge/t/to/tortoisesvn/TortoiseSVN-1.4.5-fr.pdf (consult le 20.05.2009) [Page Brooks 2008], Partage dinformations entre dveloppeurs, http://pagebrooks.com/archive/2008/05/20/using-nant-with-.net-3.5.aspx (consult le 16.09.2009) [Refactoring 2009], http://www.refactoring.com/catalog/extractMethod.html (consult le 06.05.2009) [rkcole 2009], Code Metrics: Cyclomatic Complexity and Unit Tests,

http://www.rkcole.com/articles/other/CodeMetrics-CCN.html (consult le 05.05.2009) [SourceForge 2010], Site pour le tlchargement du serveur dIC CC.NET, http://cruisecontrol.sourceforge.net/download.html (lien 1, consult le 18.05.2010), Site pour le tlchargement de Nant, http://nant.sourceforge.net (lien 2, consult le 19.05.2010) [Stelligent 2008], Site officiel de Stelligent, serveur dIC payant,

http://www.stelligent.com/content/view/54/71/1/2/ (consult le 16.05.2009) [TeamCity, 2009], Site officiel de TeamCity, serveur dIC payant,

http://www.jetbrains.com/teamcity/delayed_commit.html (consult le 08.06.2009) [Test early 2009], Site/blog pour le Management des Builds et l'IC,

http://www.testearly.com/ [TortoiseSVN 2010], Site officiel dinformations et de tlchargement de TortoiseSVN, http://tortoisesvn.net/about (consult le 09.06.2010) [ThoughtWorks 2010], Site de partage dinformations, ax IC,

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix (consult le 19.05.2010) [Wikipedia 2010], Encyclopdie (lien 1, libre , consult le

http://fr.wikipedia.org/wiki/Internet_Information_Services

11.05.2010), http://en.wikipedia.org/wiki/Branching_%28software%29 (lien 2, consult le 20.05.2010), http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_de_versions (lien 3, consult le 07.06.2010), http://fr.wikipedia.org/wiki/Subversion_(logiciel) (lien

11 Bibliographie

65

4, consult le 11.05.2010) , http://fr.wikipedia.org/wiki/Apache_Maven (lien 5, consult le 29.08.2010), http://en.wikipedia.org/wiki/Snapshot_%28computer_storage%29 (lien 6, consult le 14.09.2010) [Wuala 2010], Site officiel dinformations et de tlchargement de Wuala, http://www.wuala.com/ (consult le 25.08.10)