Outils de développeur ALM et .NET : quelles alternatives à TFS ?

Historiquement, le métier de développeur se rapproche bien plus de l’artisanat que de l’industrie. Entendons-nous bien. Le terme d’artisanat n’a ici rien de péjoratif. Pas plus que le terme d’industrie, d’ailleurs. D’ailleurs, que nous dit Wikipedia ?

ArtisanatL’artisanat est la production de produits ou services grâce à un savoir-faire particulier et hors contexte industriel : l’artisan assure en général tous les stades de sa production, ainsi que la commercialisation de celle-ci. 

Industrie : L’industrie est l’ensemble des activités humaines tournées vers la production en série de biens ; elle sous-entend :

  • une certaine division du travail, contrairement à l’artisanat où la même personne assure théoriquement l’ensemble des processus : étude, fabrication, commercialisation, gestion :
  • une notion d’échelle, on parle de « quantités industrielles » lorsque le nombre de pièces identiques atteint un certain chiffre.

Historiquement, le terme a d’abord désigné l’habileté à faire quelque chose, puis toute forme d’activité productive, et non seulement celle produisant des biens matériels. Ce dernier sens a vieilli, mais il domine encore en anglais.

Donc si l’on résume, l’artisan :

  • a un savoir-faire
  • est polyvalent
Alors que dans l’industrie :
  • le travail est divisé
  • les tâches sont répétitives

Et le développeur dans tout cela ?

Revenons à notre développeur. Où se place-t-il ? La réponse à cette question est en fait bien plus complexe qu’il n’y parait, et quoi qu’on en dise, on en viendra à une réponse de Normand. La vérité se trouve quelque part au milieu. D’autant plus que 2 mouvements semblent a priori prendre des voies opposées : les partisans de l’industrialisation du génie logiciel et les partisans du Software Craftsmanship, poussés par des petits gars comme Martin Fowler ou Uncle Bob Martin et dont nos aimables voisins d’à côté nous parlaient il y a peu. Ces deux tendances sont-elles réellement contradictoires et incompatibles ?
Quel est le métier d’un développeur ? Développer du logiciel. Très bien. Quelles sont ses tâches au quotidien ? Elles se composent de tâches répétitives et de tâches uniques, exécutées pour la première et dernière fois. Par définition, chaque logiciel est unique, de par le besoin auquel il répond, ses utilisateurs, ses contraintes d’exécution et enfin son architecture et sa conception.
Et toute la problématique est précisément là : comment assister le développeur, l’aider à dégager du temps de cerveau disponible pour être réellement efficace sur les tâches où le cerveau humain a une réelle valeur ajoutée. Et, miracle, c’est précisément le but de l’usine logicielle. Décharger autant que possible le développeur de ses tâches répétitives, l’assister, de façon à le laisser pouvoir se concentrer sur les tâches où son cerveau a une réelle utilité.

Qu’est-ce qu’une usine logicielle ?

Une usine logicielle s’inscrit dans une démarche de gestion complète du cycle de vie d’une application. Microsoft appelle cette dernière Application Lifecycle Management (ALM), et l’adresse avec son offre Team Foundation. L’idée est donc de proposer des solutions pour chacun des maillons du cycle itératif de la vie de l’application.

développeurs Application Lifecycle Management

 

Nous retrouvons dans ce schéma l’ensemble des étapes de la vie d’une application :

  • Le recueil des besoins
  • L’architecture
  • La conception, le développement
  • Les tests
  • La qualimétrie
  • Le déploiement
  • La gestion des changements

Et par-dessus tout ceci, des éléments transversaux : l’Intégration Continue, la gestion de la dette technique, la gouvernance… Microsoft propose une solution clé en main, Team Foundation Server (TFS). La solution est bonne, voire excellente, pour peu qu’on ait les budgets. L’intégration entre le serveur TFS et Visual Studio est très forte. Pour des raisons diverses, cette solution n’est ici pas retenue. Premièrement, pour donner un sens à cet article. Ensuite, et plus sérieusement, nous avons choisi de nous orienter plutôt vers une solution plus ouverte vers l’extérieur, et si possible gratuite. Il est fortement envisagé d’inclure dans notre usine des solutions RubyOnRails. Même si TFS n’est plus cantonné à 100% aux technologies Microsoft, la plateforme leur reste tout de même intimement liée.

Quelles sont donc les alternatives ? Détaillons ses composants.

La gestion de projet

Nous avons tout d’abord besoin d’un outil qui sera partagé par l’ensemble des personnes impliquées. Dans un projet Scrum, le Management, le Product Owner et l’équipe devront partager des informations. Les critères obligatoires pour l’outil choisi seront donc :

  • la présentation d’une photo de l’état du projet, ainsi que son historique et différentes métriques de suivi
  • un accès web pour les personnes hors-projet
  • une liaison au contrôle de sources
  • et surtout, l’adoption par l’équipe
Idéalement, les différentes tâches sont accessibles à partir de l’IDE utilisé par les développeurs.
La shortlist retenue pour notre projet Scrum est :

Et l’heureux vainqueur est VersionOne. Ce dernier offre l’avantage d’être gratuit pour une utilisation basique et entièrement hébergée chez l’éditeur, ce qui laisse l’équipe monter en compétence et progresser à moindres frais. Une fois les limites atteintes, une version payante offre des métriques supplémentaires, des possibilités de paramétrage plus poussées et un support éditeur. De plus, l’éditeur fournit des connecteurs vers bon nombres d’IDE, de serveurs d’Intégration Continue, ainsi qu’un SDK.

Le contrôle de sources

C’est le centre névralgique de l’usine. Tout le reste est construit autour. Le code présent dans le contrôle de source fait foi, et lui seul. Nos 2 critères de choix sont :

  • L’accessibilité depuis le poste de développement : IDE et système de fichiers.
  • L’accessibilité depuis l’Intégration Continue
Deux principaux choix s’offrent à nous : SubVersion et Git. SubVersion est relativement simple à prendre en main. Une centralisation poussée du code, une branche principale, le Trunk, dont on fait dériver les branches temporaires, qui viendront rejoindre le Trunk une fois les développements terminés et ainsi de suite. Git, en revanche, est plus puissant mais aussi plus complexe à prendre en main. Il est parfaitement adapté à un environnement distribué, avec des équipes éparpillées, comme un projet open-source. En contrepartie, certaines notions sont obligatoirement à appréhender avant de travailler correctement.

Le choix entre ces deux dépend surtout du niveau d’expérience de l’équipe, et de la distribution géographique de l’équipe. Dans notre cas, ce sera Git, car plusieurs développeurs ont déjà leurs habitudes dessus, accélérant la prise en main par l’équipe.

L’intégration continue

Le serveur d’intégration est le second élément central de notre usine. Il se branche directement sur le contrôle de sources, et effectue plusieurs actions sur ce dernier :

  1. Compilation
  2. Exécution des tests unitaires
  3. La qualimétrie
  4. Génération de la documentation
Pour cela, il exécute un script MSBuild, que nous paramétrons nous-mêmes. Les résultats doivent ensuite être exposés via une interface web, et un mail d’erreur doit être envoyé à l’équipe en cas de build échoué.

Notre shortlist :

Nous retenons Jenkins. Le produit a le bon goût d’être open-source avec une communauté très active autour. De multiples plug-ins sont disponibles et le paramétrage très aisé.

L’environnement de développement

Pas de grosse surprise ici, nous retenons Visual Studio 2010 en tant qu’IDE. Des alternatives existent : SharpDevelop et MonoDevelop, mais elles ne sont pas jugées suffisamment matures ni suffisamment pérennes pour un projet en entreprise à longue échéance.

Les tests unitaires

Deux solutions là encore s’offrent à nous : le vénérable NUnit, portage des célèbres xUnit pour .NET et MSTest, la réponse de Microsoft. Concernant l’écriture des tests, les différences sont réellement marginales. La syntaxe de NUnit est légèrement plus complète, mais dans 99% du temps, les tests seront écrits de la même façon avec MSTest. NUnit a pour lui son ancienneté, et donc un support très complet de la part des outils devant interagir avec les tests (Intégration Continue, calcul de taux de couverture…). En revanche, MSTest est nativement intégré à Visual Studio, quand il faut jouer avec les plug-ins avec NUnit.

Nous retenons NUnit, pour son intégration native avec Jenkins.

La qualimétrie

Ce paragraphe a fait l’objet d’un article à part entière. Nous retenons donc :

Dans un deuxième temps, Sonar sera utilisé pour centraliser et historiser les mesures calculées.

La documentation

Ici encore, je vous renvoie vers cet article traitant du sujet. La documentation technique doit être écrite par les développeurs directement dans l’IDE, assemblée par l’Intégration Continue et exposée à la fois publiquement (un intranet par exemple) et à nouveau dans l’IDE. Nous utiliserons donc :

Conclusion

Les outils étant choisis, nous les installons, les intégrons et nous nous en servons chaque jour. La grande question est : que vaut cette solution, comparée avec la solution intégrée Microsoft ?

Avantages :

  • Un coût minime : hormis Visual Studio, l’ensemble des outils retenus  est gratuit et le plus souvent open-source. Il existe des versions payantes de certains éléments (VersionOne, GhostDoc), mais nous nous contentons pour le moment des versions gratuites.
  • Une ouverture à d’autres plateformes et langages : Git et Jenkins seront parfaitement à même d’intégrer tous types de projets : PHP, Java, RubyOnRails…
Inconvénients :
  • Le coût d’intégration : le temps passé à intégrer n’est pas énorme, mais ça n’en reste pas moins un coût.
  • Une intégration moins forte qu’une solution packagée : l’utilisation quotidienne de notre ensemble est moins facile que d’utiliser TFS. Le résultat est une somme de petites frustrations et de petites pertes de temps. Ces éléments ne sont pas à négliger sur la durée totale d’un projet.

8 Commentaires Laisser un commentaire

Benjamin ROBIC
octobre 26, 2011 13:46

Bonjour,

Actuellement en train de finaliser mon mémoire (que je dois rendre ce lundi) sur l’Usine Logicielle en .Net, je suis heureux de voir que vos choix rejoignent les miens.

Cependant, il y a une « brique » que je considère et dont vous ne parlez pas à savoir le problème des dépendances. Avez-vous un avis là-dessus?

Dans l’univers Java, ils ont la chance d’avoir Maven qui va, en même temps que « builder », récupérer et gérer les dépendances. En .Net, Maven est en cours de portage via NPanday mais j’ai jugé que le projet n’était pas assez mature pour être vraiment efficace.
Je me suis alors tourné sur NuGet qui permet de gérer les dépendances, mais uniquement cela.

Je souhaiterai avoir votre avis sur cette question si vous avez étudiez le sujet.

Merci d’avance!

Cordialement.

Répondre
Christophe H
octobre 26, 2011 15:34

Bonjour Nicholas,

Merci pour cet article.
Je voulais cependant donner mon avis sur certains points.

Il me semble que les coûts de TFS 2010 sont relativement faibles pour outiller une équipe comparés aux coûts de Visual Studio 2010 (assez exorbitants pour la version Ultimate), surtout si l’équipe comporte 5 développeurs maximum ou si l’on dispose d’abonnements MSDN.
As-tu eu le temps de comparer ces budgets ?

Concernant l’ouverture de la plate-forme, cela reste certes un point faible mais MS fait pas mal d’efforts sur cet aspect-là ces derniers temps. Le développement en PHP est possible dans Visual Studio. De même, la connexion à TFS est possible depuis un autre IDE comme Eclipse avec Team Explorer Everywhere.

Par ailleurs, le choix de Git n’est à mon avis valable que si l’on préfère un outil de contrôle de sources distribué plutôt qu’un centralisé. C’est un choix qui va donc plutôt dépendre de la culture de l’équipe.

Le gros avantage de TFS pour moi , même s’il n’est pas le meilleur sur chacune des briques, est d’avoir une solution intégrée en tout point.

Pour info, il y a eu récemment un thread un peu enflammé à ce sujet sur la mailing list Alt.Net :
https://groups.google.com/group/parisaltnet/browse_thread/thread/72d08f7731b571e7?hl=fr

Répondre

Christophe> On est plutôt d’accord dans le fond. J’aime beaucoup TFS. Et effectivement, bien que la solution ne soit pas gratuite, elle n’est pas (ou en tout cas plus, depuis TFS 2010) hors de prix.
En ce qui concerne les versions de VS, nous utilisons la Pro.

Et entièrement d’accord avec toi sur les qualités de TFS. Et il faut aussi prendre en compte l’amélioration progressive de la plateforme. 2010 a été un gros pas en avant, d’ailleurs.

Cet article n’est certainement pas là pour dénigrer la solution, mais plutôt pour répondre à la question : si on ne prend pas TFS, que prend-on ?

Répondre

Dans le monde .NET, la problématique des dépendances est en règle générale moins forte que dans le monde Java étant donné qu’on va s’appuyer en grande partie sur des composants du Framework et les composants développés sur site. Ensuite, les dépendances restantes se gèrent en phase de développement, et NuGet est un bon outil pour récupérer les paquets à intégrer.

Ensuite, pour valider les principes d’architecture et la gestion des dépendances, on peut s’appuyer sur NDepend ou les outils d’architecture natifs de VS, mais ces derniers ne sont inclus que dans la version Ultimate.

Le Build, lui, est confié à MSBuild ou NAnt. C’est le builder qui va exécuter la compilation, agréger les resultats des tests unitaires, calculer le taux de couverture, etc., et mettre à disposition les résultats à l’IC.

Après, il existe NMaven, portage de Maven sur .NET, mais ça ressemble quand même à faire rentrer des carrés dans un trou rond.

Voilà, j’espère que ça répond à ta question, ou au moins que ça donne des pistes de réflexion !

Nicholas

Répondre
Benjamin ROBIC
octobre 27, 2011 07:55

Bonjour,

En effet, il est clair qu’en .Net, la problématique des dépendances n’est pas aussi importante qu’elle peut l’être en Java. Mais en .Net, on a quand même tendance à souvent se servir de librairies externes et donc c’est là où NuGet est intéressant car il gère cela parfaitement.

NMaven que vous me citez est en fait devenu NPanday, c’est de cela dont je parlais précédemment. Pour l’avoir testé, il peut être intéressant mais pas en l’état actuel. Manque de maturité.

Pour le build oui, MSBuild ou NAnt conviennent parfaitement mais ce que je cherchais à voir c’était si NPanday pouvait le faire pour résoudre le problème des dépendances directement dans le builder, comme le fait Maven.

Merci en tout cas.

PS: Pour la partie Intégration Continue, j’ai testé TeamCity aussi de JetBrains (Resharper, dotTrace, …). Il est vraiment très bien fait et propose des fonctionnalités très intéressantes comme les « Pre-Tested Commit ». Cependant, il manque encore de maturité et de documentation ce qui m’a fait priviligier également la piste Jenkins.

Répondre
Christophe H
octobre 27, 2011 14:31

Benjamin> Du peu que j’ai utilisé, Nuget est assez bien foutu je trouve.
Sinon tu peux peut-être jeter un œil à OpenWrap.

Répondre

Votre article est très intéressant. Je suis ravi de voir que d’autres ont les même velléités, à savoir tenter l’expérience avec d’autres outils que VS/TFS !

Par contre, deux questions me sont venues à l’esprit :

– Vous utilisez VersionOne en trial ? C’est bien payant, non ? Est-ce qu’il s’intègre bien à VS ?

– Hébergez-vous vous-même un serveur Git ? sous linux ? ou bien utilisez-vous un hébergeur ?

Merci d’avance

Répondre

La version Team Edition (http://www.versionone.com/pricing_and_editions/) de VersionOne est gratuite. Elle est limitée à 10 utilisateurs, et n’est pas customisable. Mais ça reste satisfaisant pour une utilisation basique.

Il y a un plugin VS, ainsi que pas mal d’autres (http://www.versionone.com/Platform/Integrations.asp), mais je ne m’en suis pas encore servi.

Concernant Git, nous l’hébergeons nous-mêmes.

Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *