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

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.

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 ?

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…

J’y serais présent les deux premiers jours (12 et 13 février), donc si vous voulez qu’on s’y croise, n’hésitez pas à me contacter !

Et si vous trouvez que je ne poste pas beaucoup ces derniers temps… et bien à défaut de partager, j’apprends beacoup de nouvelles choses

Depuis que je travaille en centre-ville, je suis à la merci de la moindre panne du Tram. Le site InfosTBC offre sur son site, le moyen d’être informé en temps-réel des pannes par flux RSS. Malheureusement, cela implique de se connecter sur le site ou sur son lecteur RSS pour connaître l’état du réseau.

Mon côté Geek-User m’a fait chercher une solution plus mobile et surtout gratuite…

Cette « astuce » consiste donc à utiliser Twitter qui permet de recevoir les notifications d’amis par messages SMS.

La procédure est la suivante :

1. Créer un compte Twitter si vous n’en possédez pas

2. Ajouter dans sa liste d’ amis le twitter de TBC qui est un compte créé par mes soins. Le Twitter de TBC publie le contenu du flux RSS disponible sur le site officiel et se rafraîchit toutes les 10 minutes.

3. Activer la notification des SMS. Cela nécessite d’ajouter son numéro de téléphone sur son compte Twitter et d’envoyer un SMS en angleterre (un et un seul!).

C’est l’unique coût de l’opération

4. Bien vérifier que la notification mobile est active pour le « friend » TBC.

Et c’est tout.

PS : Si vous avez vraiment du temps à prendre vous pouvez également m’ajouter dans votre liste…

Au début de la vulgarisation du web, il était courant de trouver des grandes marques dont le nom était squatté. Vois l’affaire McDonalds (qui remonte tout de même à 1994) dont le nom a été enregistré par un particulier. Plus près de nous, il existe le célèbre france2.com (dont je ne tiens pas à linker et qui est en plus NSFW). Je suis d’ailleurs étonné de voir que le lien fonctionne encore…

Les marques sont désormais bien au courant de ce genre de phénomène et il est commun de voir un nom de domaine squatté revenir au détenteur de la marque. Voir l’épisode Milka litigieux.

Le phénomène à la mode, c’est de béneficier de la renommé des gros sites « web2″ et de réserver le nom de domaine national.

Pour Facebook, cela donne :

• facebook.jp
• facebook.de
• facebook.fr (mauvais exemple, mais il marchait encore il y a une semaine…)
• …

Pour Twitter :

• twitter.fr
• twitter.de
• twitter.jp
• …

Et pour d’autres exemples : jajah.fr, technorati.fr , technorati.de.

Essayez avec vos sites américains et vous serez étonné du nombre de squat existants. Le succès de ces sociétés américaines n’a pas été pensé à l’internationnal alors qu’une version française de facebook existera un jour !

C’est d’ailleurs un gros avantage des sociétés européennes. Avoir des pays voisins ne parlant pas la même langue provoque la refléxion sur les problèmatiques d’internationalisation et de localisation.

Petit Quizz : Différence entre Localisation et Internationalisation ? Réponse dans les commentaires…

C’est ainsi que netvibes (projet franco-anglais) répond correctement aux différents noms de domaines co.uk, fr, jp, … (le .de échoue, c’est étonnant).

La conséquence d’avoir une refléxion portée sur l’international est de penser également aux traductions du site pour les différentes langues. A ce sujet, Netvibes utilise le principe du « user content generated » (contenu généré par les utilisateurs).

Lorsque vous choisissez votre langue dans les options, vous voyez l’état d’avancement de la traduction :

Les utilisateurs sont alors invités à participer aus « netvibes translators » afin d’améliorer la localisation du site.

Il est ainsi étonnant de voir que des sites aussi importants que facebook ou twitter ne possèdent ni versions traduites ni noms de domaines nationaux. C’est d’ailleurs une opportunité qui permet à certains acteurs nationaux d’avoir une version « pays » comme CopainsDavant ou Cdiscount.

1. S’ouvrir aux autres

La première raison est la plus évidente, augmenter la visibilité de notre pensée. Un blog est un méga-phone dont les paroles peuvent atteindre le milliard d’humains connectés (on va limiter pour le mien car il est écrit en français… )

Les moments où l’on peut exprimer pleinement notre pensée de A à Z sont un luxe et un blog permet justement cela.

De plus, cataloguer, rationnaliser nos idées permet de les ressortir plus facilement en situation réélle et augmente notre pertinence.

2. Notre nom est une marque

Idée fondamentale dans la création de mon blog, je souhaite me construire une « autorité » par mes différents articles. Le lecteur peut donc être un ami, un collègue, mais aussi un futur patron.  Pour cela, j’applique les règles de bien-séance afin d’avoir un site aussi « propre » que possible.

3. Exprimer implique un travail sur soi

Finalement, ce que m’a le plus apporté l’écriture c’est ce travail de réflexion sur soi. Une idée en tête doit se transformer et évoluer avant de devenir un article. J’ai donc appris à relativiser la technologie. Plus besoin de s’enflammer sur la sortie de telle nouvelle version ou sur une annonce de nouveau produit. Je prends du recul et de plus en plus… (ou sinon c’est peut-être l’âge qui fait ça )

Si vous voyez d’autres raisons, n’hésitez pas à commenter.