• Partie 1
• Partie 2

Construction continue

Nous disposons maintenant d’un programme dont la construction est automatisée. La prochaine étape est de déclencher notre script de compilation automatiquement, d’où le terme de continu.

Pour cette étape, c’est CruiseControl.Net (http://confluence.public.thoughtworks.org/display/CCNET) qui sera utilisé.

Son principe est de surveiller un « repository » (subversion ou dans notre exemple, un dossier). Lorsqu’il détecte un changement, il va déclencher automatiquement la construction en exécutant NAnt et générer un rapport. De plus, il mettra à notre disposition le livrable résultant.

Après avoir installé l’outil, par défaut dans « c:\program files\CruiseControl.Net », nous allons le configurer.

Encore une fois, c’est un fichier xml de paramétrage que nous allons devoir renseigner. Son nom est « cconfig.config » et nous le placerons à la racine de notre projet, au même niveau que le script de compilation.

Figure : ccnet.config

Les différents paramètres positionnés sont :

• La source de données : Pour nous c’est un simple répertoire du système de fichiers. Dans un projet plus conséquent, c’est ici que nous positionnerions la connexion au serveur subversion.

• La temporisation : 2 secondes d’attente entre chaque vérification. Cela signifie que tout changement du code source implique un délai d’attente de deux secondes avant de lancer la chaîne.

• La chaîne de lancement : On référence ici l’outil de build Nant ainsi que son fichier de build.

• Le résultat des tests unitaires est intégré au rapport (pour trouver la raison de leur échec plus rapidement le cas échéant).

Il nous reste ensuite à démarrer CruiseControl. Vous devriez voir apparaitre les logs de démarrage ainsi qu’une première compilation :

Figure : Résultat d’une compilation CruiseControl

Notre arborescence projet ressemble maintenant à :

Nous pouvons maintenant constater qu’en modifiant notre fichier de code source, nous générons automatiquement un log de construction indiquant si la compilation est réussie ou non.

Tableau de bord

La dernière étape de notre architecture consiste à mettre à la disposition des utilisateurs un moyen simple de consulter les informations générées par notre serveur CruiseControl.

Pour les développeurs, il est utile de savoir en temps réél si CruiseControl compile correctement le code du repository. En effet en conaissant au plus tôt un défaut de compilation, ils seront à même d’intervenir et de corriger les bugs apparus. Il existe diverses façons de connaitre l’état du serveur mais un des outils les plus pratiques est le « CC.NET Tray » (http://confluence.public.thoughtworks.org/display/CCNET/CCTray).

Il se présente sous la forme d’une icône dans la barre des tâches et suivant sa couleur, indique l’état de la dernière compilation.

Après installation, vous devez dans les paramètres, ajouter notre projet « localhost / ChaineManip » et valider.

Figure : CCTray en vert, tout va bien

Pour des utilisateurs comme des chefs de projets ou des architectes, l’information en temps réél n’est pas nécéssaire. En revanche, il est utile d’avoir un apercu sur la durée de l’évolution du code. Par exemple de savoir si la qualité des releases est constante et si le taux builds réussis reste dans un taux constant.

Le plus intéressant pour ce besoin est le « webdashboard » proposé par CruiseControl.Net. Lors de son installation, il propose la configuration du « dashboard » sur IIS. Ceci va installer une application ASP.NET qui se connecte au serveur CruiseControl.

Cet outil se présente donc sous la forme d’un site contenant l’historique des constructions.

Figure : dashboard CC.NET

Conclusion

L’intégration continue est l’aboutisssement d’une démarche d’industrialisation du processus de construction logicielle. La règle d’or : Tout ce qui peut être automatisé doit l’être.

La première raison à cela est d’enlever toute friction liée à la construction d’une release. En effet, comme nous l’avons vu en introduction, l’erreur est humaine et tout process automatisé supprime complétement le risque d’erreur liéé à  des opérations manuelles et non reproductibles.

La seconde raison est d’augmenter la confiance dans notre maitrise du risque technique. Nous pouvons garantir qu’à un instant T, le projet compile, les tests unitaires passent, etc. Ceci a son importance dans le sens où l’on évite l’effet tunnel et le risque d’intégration au dernier moment.

Si vous souhaitez aller plus loin sur ce thème, il est possible d’ajouter des étapes intermédiaires à notre chaîne. On pourrait ainsi mettre en place des outils d’analyse de code et de génération de métriques. On pourrait également terminer le build NAnt par la construction d’un package prêt à la livraison (zippé, date de contruction,…) ou par l’envoi d’un email de notification au client ou à l’équipe de QA.

Compilation / Build

La seconde étape de mise en place est la réalisation d’un fichier de compilation. Pour cela, nous pouvons nous appuyer sur l’outil open source NAnt (http://nant.sourceforge.net).

NAnt s’exécute en ligne de commande et prend en paramètre un fichier xml contenant les étapes à effectuer successivement pour emmener le code source dans un état prêt à l’exécution. Le fichier XML se base sur une syntaxe à base de taches contenant des actions sur un principe de dépendance entre actions. Encore une fois, cet article est pretexte à creuser chacun des outils présentés et en ce qui concerne la syntaxe de NAnt, je vous incite à utiliser la documentation en ligne de référence.

Une fois l’outil installé, il suffit de l’executer en ligne de commande. Il cherchera le premier fichier  « .build » du repertoire et traitera son contenu.

Pour notre exemple, nous allons donc créer un fichier « ManipChaine.build ».

Votre arborescence devrait ressembler à ceci :

La liste des actions de construction sera :

• Nettoyer le repertoire de sortie (les binaires)
• Compiler le code source
• Executer les tests unitaires
• Executer le programme

Notre exemple est trivial, mais un « vrai » script de construction peut contenir des dizaines d’instruction (zip de fichier, transfert ftp, redémarrage de serveur web). L’objectif étant d’avoir la possibilité, en partant des sources, d’effectuer toute la livraison jusqu’à l’étape déployable (ou même déployé).

Figure : ChaineManip.build

Testez votre script en démarrant « Nant.exe » depuis le dossier \CI. Attention, vous devez utiliser une fenêtre MS-DOS possédant une référence au compilateur C#. Je vous recommande donc la ligne de commande VS qui se situe dans le menu Démarrer / Visual Studio / Outils.

Vous devriez ainsi voir :

Comme on peut le constater, le build est « succeded ». Cela implique que la compilation a réussie et que les tests unitaires sont passés avec succès.

De manière générale, la notion de script de compilation est essentielle et s’oppose à celle de construction par un poste de développeur. La raison principale est de limiter la dépendance à la configuration propre à chaque développeur (cf : « The F5 Key Is Not a Build Process » – http://www.codinghorror.com/blog/archives/000988.html).

Cet article est sorti du tiroir puisqu’il a 2 ans, mais il reste totalement d’actualité.

Origines

On oppose généralement l’aspect industriel du développement à l’artisanal. Pour mieux saisir la signification de ce terme, je vous propose une petite histoire :

Après quatre mois de développement, c’est le grand jour de la livraison. Georges, après avoir testé une dernière fois que son code compile, décide de déployer la version finale du site Intranet de la mairie.La démarche est maitrisée puisque cela fait maintenant une vingtaine de fois qu’il a répété l’opération. Comme à chaque fois, il commence par demander à son collègue sur quels fichiers il a travaillé. La liste connue, il récupère par le réseau ces fichiers, puis tente de compiler le projet. Chance, tout compile. La suite est plus délicate, Georges doit se connecter à distance au serveur, migrer la base de données et insérer les données mis à jour. Vient ensuite la partie copie des fichiers sur le serveur et redémarrage du serveur. A ce moment, si tout va bien, le site devrait être mis à jour. Malheureusement, au premier test, impossible de se logger.

Si cette scène vous rappelle quelque chose, pas d’inquiétude car c’est courant et aujourd’hui de nombreuses sociétés fonctionnent dans ce mode de gestion. Mais l’industrialisation et l’automatisation sont maintenant un but plus facile que jamais à atteindre grace à de nombreux outils. Preuve en est également l’implication de Microsoft sur le thème « Gestion du cycle de vie logiciel » et la fourniture d’une offre complète avec la suite Team System et son serveur Team Foundation Server.

Néamoins pour des raisons de simplicité, nous nous attacherons ici à présenter les concepts de l’intégration continue à l’aide uniquement d’outils open-source.

Concept

Figure : Schématisation d’une chaîne d’intégration continue

L’intégration continue est un concept qui se base sur l’analogie avec une usine automatisée. Sauf qu’au lieu de constuire des voitures, on construit un logiciel. Cette « usine » est construite sur l’enchainement suivant :

1. Un développeur travaille en local. Lorque ses modifications sont terminées, il archive son code sur un serveur gestionnaire de sources.
2. A la detection d’un changement (ou suivant une règle temporelle paramétrée), le serveur d’intégration récupère la dernière version des sources et déclenche la contruction (« build ») de la solution.
3. En étape facultative mais intéressante, il est possible d’appliquer des métriques et des tests sur la solution et d’en générer des rapports
4. Enfin, la solution et le bilan de la construction sont déployés sur un serveur de résultat accessible à l’équipe projet. Dans le cas d’un sous traitance, ce portail peut aussi être mis à la disposition du client pour qu’il puisse constater l’avancement du projet. (Particulièrement utile dans le cadre d’une démarche agile).

Mis en pratique

Après ces concepts théoriques, nous allons nous attaquer à la réalisation de notre chaine d’intégration continue. Afin de garder un ensemble cohérent, nous restreindrons notre programme à une unique classe effectuant une manipulation sur une chaîne de caractères. Cette chaine sera fournie au programme en ligne de commande et le résultat sera affiché à l’écran.

Le programme

Il s’agit d’une classe « ChaineManip » qui contient une méthode « Manip ». La méthode Manip prend 2 strin en paramètre et affiche sur la sortie le résultat de l’opération. Afin de pouvoir être executé directement en ligne de commande, cette classe possède également une méthode Main qui délègue l’appel à ChaineManip.Manip. Voici le code :

Figure : ChaineManip.cs

Tests unitaires

La démarche d’industrialisation s’accompagne naturellement d’une meilleure gestion des tests unitaires automatisés. Si vous n’avez encore jamais utilisé de framework, je vous invite à découvrir cette méthodologie (http://www.dotnetguru.org/articles/outils/tests/nunit/nunit.htm).

Dans notre cas, c’est le framework Nunit (http://www.nunit.org) que nous allons utiliser.

Pour nous simplifier la tâche et éviter des soucis de compatibilité, nous allons utiliser les DLL fournis dans l’installation de NAnt (installé au chapitre suivant) et donc nous passer d’une installation de NUnit.

Nous allons ainsi créer une classe de test « ChaineManipTest.cs » qui testera l’unique méthode « Manip » de notre classe programme. Sans entrer dans les détails, le code suivant teste le résult de l’appel de la méthode en le comparant avec un résultat attendu.

L’objectif est de compiler le code de notre programme et d’exécuter les tests unitaires dans la continuité. Si un problème est détecté à l’exécution des tests, la construction est stoppée et la release jugée non fiable.

Figure : ChaineManipTest.cs

Contrôle de source

Un gestionnaire de source est la pierre angulaire d’une organisation projet. Si vous n’avez jamais utilisé d’outil de ce genre, je vous incite à vous pencher fortement sur le sujet à travers des articles tels que http://dev.nozav.org/intro_svn.html.

Le principe est donc d’avoir ce serveur à la disposition de l’équipe. Quand un développeur a terminé une modification sur le code, il vérifie que sa modification compile sur son poste puis envoie les sources modifiés sur le serveur. L’outil le plus adapté pour notre chaîne est « Subversion » (http://subversion.tigris.org). Bien qu’en réalité il ne faudrait pas mettre en place de chaine d’intégration continue sans un bon gestionnaire de source, nous allons simplifier notre chaine en utilisant un simple dossier comme « repository » de code.

La suite Partie 2.

Celui-ci est accessible ici : http://blogms.sqli.com/

Sinon, j’ai profité de la sortie du .NET 4.0 ainsi que de Visual Studio pour écrire mon premier article dans un magazine papier.

Il s’agit du Programmez! de Mai 2010 n°130.

Vous pouvez le retrouver en kiosque ou l’acheter en PDF en ligne directement. Donc n’hésitez pas et si vous avez des questions, vous pouvez toujours m’interroger ici.

Google vient donc de sortir son propre navigateur web, dont le développement a commencé il y a 2 ans. Ses principales caractéristiques sont :

• Moteur de rendu WebKit (le même que celui de Safari)
• Une gestion des fenêtres par processus avec la promesse qu’en cas de plantage, le  navigateur reste opérationnel pour les autres fenêtres.
• Un moteur Javascript qui compile le code et annonce une performance exceptionnelle.

L’objet de cet article n’est pas un énième comparatif avec Firefox ou IE mais plutôt de commenter la réussite de Google sur son lancement Produit et sur la qualité de celui-ci.

En effet, en installant un produit béta, je m’attends à subir de nombreux plantages et déconvenues mais en passant une journée complète dessus : recherches google, gmail, deezer, hotmail, installation  d’un dotnetnuke sur mon local  IIS7, je n’ai eu aucune erreur…

C’est si rare que l’on ne peut être qu’ébahi devant une telle performance !

Hotmail Fail :Ouverture d’hotmail sous chrome

Sur la BD chrome, (et oui, ils ont fait une bande dessinée pour la sortie de Chrome), Google met en avant son processus qualité et ses tests unitaires automatisés et manuels.

C’est un argumentaire de poids et un exemple qui démontre qu’avec un environnement de tests performant, il est possible d’ouvrir au public avec une version stabilisée.

On parle souvent du principe « release early, release often » qui signifie qu’il est important d’avoir un feedback des utilisateurs régulier et le plus souvent possible.  Malheureusement pour beaucoup d’équipes cela signifie un rush sur les sorties avec une qualité discutable…

J’ajouterais donc aujourd’hui un troisième principe : « release early, release often, but release it works » !

Le principe est de recommander aux lecteurs des blogs intéressants, un peu là la manière de « Mon TOP Blogs ».

Voici donc la liste des 5 blogs élus :

• http://ayende.com/Blog/ : Demi dieu sur terre venu nous expliquer le .NET. Ce type est extrêmement compétent et parle de sujet avancés tels que les DSL.
• http://blogpro.toutantic.net/ : Aurélien Pelletier nous parle du Web 2/RIA/ROA/REST. De plus j’ai eu l’occasion de le voir aux Techdays 2008  et c’est un vrai passioné.
• http://www.voxinablog.com/ : Pour des idées et des conseils sur l’e-marketing et le réferencement par François Goube.
• http://www.aubryconseil.com/ : Feedback terrain d’un agiliste français Claude Aubry.
• http://www.nioutaik.fr/ : 200 % Humour geek

On s’y retrouve ?

Présentation générale SQL Server 2008

Session intéressante car nous avons eu droit à un point de vue 360° sur les nouveautés.

Je retiens particulièrement le travail apporté sur la partie Reporting. En effet, le moteur était déjà très intéressant dans la version 2005 mais quelque peu limité dans son utilisation par des novices. Avec l’arrivée de nouveaux outils orientés « Business », cela sera un argument de plus pour ce produit.

Software+Services : Introduction

Session décevante où la première partie a consisté en la lecture des slides.

J’aurais aimé une présentation plus argumentée avec une comparaison des différents moyens pouvant être mis en oeuvre pour mettre en place du Software + Services.

Commerce Server 2007

Ayant déjà une expérience sur les problématiques e-commerce et ayant manipulé un peu Commerce Server, j’étais intéressé par le sujet. En effet, je souhaitais voir comment l’outil était manipulé par des experts du domaine. Et bien, je continue à avoir un à avis favorable sur le sujet et je pense que CS2007 est un des solutions les plus pertinentes actuelles en e-commerce prêt à l’emploi. L’aspect « Out-of-the-box » est un vrai argument avec un starter-site collant au maximum à un besoin standard.

Team System Rosario CTP

Session agréablement présentée par deux personnes de chez Winwise. Malheureusement le contenu était relativement pauvre en nouveautés. Rien de transcendant n’a été présenté mais juste des améliorations du produit. La conclusion étant de toute façon : « rien ne sert d’attendre rosario, passez déjà à Team System 2008« …

Conclusion

L’impression d’événement de l’année pour les développeurs a été amplement confirmée par le nombre de visiteurs (16 000) et la qualité des 300 sessions présentées.  Vivement les 2009

Nouveautés de C#3

Session en « speed » pour nous faire un maximum de démonstration sur les nouveautés du langage. Session la plus technique de mon parcours. Car oui je considère que si je viens aux Techndays, c’est pour m’ouvrir à des horizons et des perspectives différentes et pas pour me former en 2 jours… Néanmoins cette session fût très intéressante et a largement piqué ma curiosité sur les lambda expressions.

En dehors de ces fameux lambda, on remarquera surtout la stabilité du langage pour sa troisième version. Preuve en est la qualification de « Sucre syntaxique«  sur quasiment toutes les nouveautés du langage.

ROA – Symposium DNG

Je mets la note de meilleure session des Techdays à Aurelien Pelletier pour sa présentation sur ROA (Ressource Oriented Architecture).  J’ai apprécié d’une part le speaker qui a su nous entretenir sur le sujet pendant une heure sans temps mort et d’autre part le sujet qui préfigure d’une évolution passionnante du web. J’engage ceux qui ne connaissent pas encore le sujet à creuser tant cette façon de procéder est en adéquation avec l’utilisation du web tel que nous le faisons aujourd’hui.

Pour les slides, c’est par ici.

.NET et l’Open Source – Symposium DNG

La grosse déception de la journée mais je vais tenter d’être factuel. J’avais une attente assez forte sur cette présentation car étant un « double compétence » Java/.NET, l’intérêt d’utiliser des outils et des frameworks Open Source est une évidence pour moi. J’attendais donc de cette session des retours sur leur utilisation et quels étaient leurs conseils en la matière.

Malheureusement, Didier Girard et son acolyte se sont contenté d’expliquer les principes de l’open source avec des généralités limite (Mettre Visual Studio Express sur une liste de produits open-source par exemple), de « torcher » en 3 slides une explication du fonctionnement de Spring et de Hibernate et de conclure que leur projet a été réussi grâce à ces technos.

Je pense que le public présent n’a pas pu apprécier cette session à sa juste valeur. En effet, beaucoup de personnes présentes dans la salle connaissaient déjà des frameworks Open Source et donc , ne pas avoir d’éléments factuels, ni de comparaison technique ou grilles de décision fait que la conclusion de la session n’a apporté aucune pierre au débat.

Pour les personnes novices sur le sujet, la session a permis de dissiper un peu de F.U.D sur la peur d’utiliser de l’open source en environnement Microsoft mais dans ce cas, il fallait mieux mettre en avant et expliquer les outils Spring et Hibernate au lieu de se contenter d’afficher le code des tutoriaux. On attendait une explication plus générale et donnant l’eau à la bouche et l’envie d’installer chez soi.

Dans tous les cas, je salue le travail réalisé pour cette session qui va dans le bon sens et j’attends avec impatience les prochaines sessions sur le sujet…

On peut constater que l’importance de l’évenement va en grandissant et reste le point de rencontre majeur pour tous les développeurs Microsoft. Avec une population de plus de 15 000 visiteurs en 3 jours, la réussite de cette conférence n’est pas à questionner…

De mon point de vue, j’apprécie énormement ce genre d’évenement car j’ai l’impression d’être entouré de gens pour qui leur métier et aussi une passion et qui cherchent à toujours avancer dans leurs connaissances.

C’est aussi l’occasion de rencontrer de nombreuses personnes ou même de revoir des ex-collègues (que je salue au passage car ça fait plaisir de voir que le feeling passait toujours autant).

Après ces quelques mots, je vais me plier à l’exercice classique de description des sessions vues.

Jour 1

Pour la première journée, il y avait en parallèle le symposium DotNetGuru (DNG) dont le principe est de présenter des thèmes plus « architecturaux » et moins centrés sur la technique. Je considère que c’est une chance d’avoir accès à cette conférence intérieure et je félicite les organisateurs du choix de l’intégrer dans les Techdays. Ils ont pu toucher un public beaucoup plus large et beacoup d’intéressés (dont moi) ne seraient pas venu pour les DNG sans les TechDays  (Pour des raisons de justification de sortie entre autre).

Tout cela pour dire que cette première journée tourne beaucoup autour des sessions DNG justement

Sharepoint WCM

Pour ma première session, j’ai tenté la « Domain Driven Design » présentée par Sami Jabber mais la salle étant pleine je me suis rabattu sur la session Web Content Management sous MOSS 2007. Cette session très intéressante et bien présentée par Stéphane Cordonnier m’a rappelé beaucoup de souvenirs sur son ancêtre MCMS 2002. Mais il est heureux de constater que Microsoft a largement remis au goût du jour sa solution de CMS avec une interface Web performante et je n’ai pas retrouvé les défauts qui faisaient de MCMS 2002 un produit non fini.

Finalement pour la « Domain Driven Design », j’attendrais le webcast pour en juger mais d’après les quelques échos, la présentation devait être assez perchée !

Suite dans un prochain article…