Julien Carnelos Blog – Archives

Article en 3 parties sur l’intégration continue en technologie .NET à l’aide uniquement d’outils open-source.

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.

Vous pouvez continuer à suivre d’autres publications techniques autour du monde .NET sur le blog Microsoft SQLI.

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.

Ou la chronique d’un lancement réussi, et ce n’est pas évident pour tout le monde (pas évident tout court, il faut reconnaître).

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 » !

Pour terminer de manière exhaustive ce compte rendu, voici la description de la deuxième journée.

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 😉

Suite de la première journée :

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…

Un an et demi s’est écoulé depuis la 1.1. Le changelog est à la mesure du changement de numéro de version.

Toutes ces nouveautés paraissent bien utiles, malheureusement je n’ai plus le temps de suivre de près l’évolution de ce langage.

En effet, ces derniers temps font que je penche désormais beaucoup du coté .NET, mais je reste attaché profondément aux valeurs portées par ce framework. (Un jour peut-être que j’y reviendrais…)

C’est pour cela aussi que je vois venir avec grand intérêt le framework ASP.NET MVC dont les personnes à l’origine sont également fans de Rails.

Petite liste des fonctionnalités « inspirées » :

• Séparation des rôles : Possibilité de tester la couche Controlleur sans conteneur web
• Hautement extensif et pluggable : Comme tout est à base d’interfaces, il est facile d’intégrer un moteur d’injection de dépendance
• URL Mapping Natif : Idem des routes de Rails
• Moteur de template pour la couche présentation
• etc.

Tant mieux si Ruby on Rails peut apporter sa philosophie dans d’autres environnements, tout le monde y sera gagnant.

Un gestionnaire de source est toujours la 1ère étape dans une démarche d’industrialisation.

Si vous n’avez pas vos sources dans un référentiel au moment où vous lisez ces lignes, arrêtez-vous de suite et prenez le temps de le faire (Subversion).

La gestion de ce référentiel implique une certaine rigueur et une liste « officielle » de bonnes pratiques vient d’être publié sur le site de Subversion. J’ai repris les idées les plus intéressantes :

• Utiliser une arborescence propre

Quand on initialise le référentiel, il est facile de créer une arborescence inefficiente qu’il faudra supporter jusqu’au bout du projet. La recommandation officielle est de créer les trois dossiers : /trunk, /branches et /tags.

• Archiver des modifications fonctionnelles

Lorsque vous archivez vos modifications sur le source, celles-ci doivent être cohérentes et former un tout. Cela permettra un meilleur suivi des changements. De plus, ce changement pourra plus facilement être lié à un bug ou autre…

• Relier le gestionnaire des bugs

Il est fondamental de pouvoir être capable de relier un changement du source avec une « unité de travail ». Cette unité pouvant être un bug, une demande de changement, une évolution, etc. De ce fait, il faut associer à chaque archivage l’ID de l’item traité.

• Patient avec les gros fichiers

Subversion sait gérer le versionning des fichiers binaires mais de manière générale, manipuler ces fichiers engendrent des problèmes de latence qui peuvent devenir important. En effet, les fichiers sont copiés plusieurs fois en plusieurs endroits (dans le temp, dans le working local, …) et sur de gros transferts, le développeur devra être patient.

• Savoir quand créer une branche

Point critique, car la création d’une nouvelle branche n’est l’affaire que d’un compromis. Compromis entre l’avantage de pouvoir écrire du code non dépendant de la branche principale avec l’inconvénient de devoir un jour fusionner la branche avec le code principal.

A cette problématique, la réponse est question de contexte. Néanmoins trois stratégies se distinguent :

1. Aucune branche : Demande une forte discipline de la part des développeurs qui devront minimiser les risques de « break » du build.
2. Branche pour toute évolution : Chaque évolution est micro-managée et validée avant intégration dans la branche principale. Adapté aux gros projets possédant une équipe dédiée aux builds.
3. Branche pour les dev > 10j. Il s’agit de définir une limite où les développements qui nécessitent plus de temps se feront dans une branche à part. Pour information, c’est la technique employée dans l’équipe de développement du serveur Subversion.

Comme toujours, beaucoup de ces pratiques sont l’œuvre du bon sens. Si vous possédez également des techniques intéressantes, n’hésitez pas à partager 😉

Dans le monde web, un principe de base d’avoir le moins de friction possible. Le cas d’école est un processus de vente sur un site de e-commerce où l’on voit s’afficher en haut de la page « Etape 1/12« . Le taux de transformation (achat validé) se résume à ceux qui auront le courage d’aller au bout des douze étapes supposés. Autant dire beaucoup d’abandons !

Une autre friction importante est celle de la création d’un compte. C’est pourtant l’étape cruciale qui nous fait passer de simple anonyme à client. C’est un lien que le client crée de lui même en acceptant de s’incrire sur le site parce qu’il est convaincu du bien fondé de son choix. C’est un acte fort et engageant.

Et pourtant, les exemples ne manquent pas de voir s’afficher un formulaire de 3 pages avec une quinzaine de zones à remplir jusqu’à l’âge de mon chat…  C’est un peu comme si on entrait dans un magasin pour acheter des chaussettes et qu’un vendeur nous saute dessus pour prendre des mesures des pieds à la tête…

Certaines sites font des efforts, voir ici Twitter qui demande le minimum vital pour s’incrire :

C’est aujourd’hui la tendance la plus commune et la plus pertinante dans cette logique d’abaissement de la barrière d’entrée.

Mais on peut mieux faire.

Lorsqu’un visiteur vient pour la première fois sur un site, on l’authentifie grâce à un cookie session. Ce cookie permet de reconnaitre le visiteur pendant la durée de sa navigation sur le site. Mieux, le cookie peut être rendu persistant et dans ce cas, il reste dans le cache du navigateur autant que le site le souhaite.

L’idée est donc d’utiliser ce lien (le cookie) qui unit visiteur et site pour faire du visiteur un privilégié. 

Un exemple qui implémente parfaitement ce concept est Netvibes.

En effet, la première fois que l’on se connecte sur ce site, on se retrouve devant une page portail pleine. On peut alors s’amuser avec le site et déplacer, bouger et remplacer les blocs…

Si je ferme mon navigateur et que je reviens 1 mois plus tard sur netvibes (je confirme le mois, je viens de tester), grâce au cookie persistant, Netvibes a retrouvé mon identité et m’affiche le portail tel que je l’avais laissé la dernière fois ! 

Ce sentiment de « privilégié » incite fortement l’utilisateur à s’incrire car il a déjà investi du temps à « jouer » avec le site, donc pour ne pas tout perdre, le mieux est de s’incrire…

Je ne resiste pas à l’envie de vous citer cet extrait.

Blog Driven Developpement (BDD) :

Consacré aux développeurs qui pensent constamment au sujet de leur prochain post. Presque chaque ligne de code intéressante qu’ils produisent finit en post sur leur blog.

J’ai des noms… 😀

Via VDU.

Comme on dit, « L’accessiblité est l’affaire de tous ».

Pourtant, c’est une pratique que l’on retrouve rarement mise en place dans les projets web. Le site Pompage.net propose une explication :
10 raisons expliquant pourquoi les clients n’ont que faire de l’accessibilité que je trouve très pertinente…

Le tableau dressé n’est pas encourageant mais ils proposent quelques voies de sortie intéressantes. Pour ma part, je retiendrais surtout le fait de vendre l’accessibilité comme une exigence fonctionnelle et non plus comme un problème technique.