Usine de développement .NET avec Git et TeamCity

A travers cet article, nous voulons montrer qu’une forge logicielle composée de Git et TeamCity peu très bien convenir pour un projet en .NET

Généralement, l’association .NET/Team Foundation Server est presque toujours automatique.

Plusieurs raisons peuvent expliquer cela :

• L'intégration poussée avec Visual Studio, Office
• La popularité de TFS en entreprise et les politiques qui contraignent son adoption
• C’est du Microsoft
• Un outil All-in-One permettant la gestion des sources, la gestion des builds, le suivi des tâches, la revue de code, la planification, la gestion de projet, l'analyse des performances

Finalement, ce choix n’est pas souvent fait par l’équipe de développement elle-même. Sur un de nos derniers projets en .NET, nous avons eu la liberté de choisir notre propre UDD et de l’intégrer nous-même. Nous voulions qu’elle corresponde au mieux à nos besoins en la composant uniquement des briques nécessaires et respectant les standards :

• Un gestionnaire de code source
• Une plateforme d’intégration continue
• Un repository d’artefact

Git comme gestionnaire de code source

Notre choix s’est porté sur Git car il constitue actuellement le nouveau standard et est récent. Cela est renforcé par l’existence de sites web collaboratifs basés sur Git comme GitHub et Gitorious.

Il existe deux façons d’utiliser Git avec Visual Studio :

• En ligne de commande bash
• Avec des extensions pour intégrer les commandes Git dans Visual Studio : Git Source Control Provider et Git Extension

A noter qu’un développeur ne connaissant pas Git sera probablement dérouté, ce n’est pas le même paradigme; Git est un DVCS et nécessite de réfléchir autrement. C’est un point à prendre un compte, une formation ou équivalent est sans doute à envisager.

Les extensions permettent de s’affranchir de la ligne de commande, cela représente un confort pour certains et se rapproche plus d’une utilisation avec TFS, sans pour autant obtenir le même niveau d’intégration.

Un point d’attention concerne la gestion des conflits, quelque peu déconcertante. De plus, l’outil de merge proposé par défaut (kDiff) nécessite un temps d’adaptation.

Toutes les opérations usuelles de Git telles que : commit, push, clone, pull, fetch, stash (et bien d’autres) sont gérées et s’effectuent dans des interfaces dédiées.

Intégration des extensions Git dans visual Studio 2012

Intégration continue avec TeamCity

Nous avons choisi TeamCity car l’outil possède certains avantages :

• C’est un outil découplé de l’IDE utilisé
• Le build se paramètre via un enchainement de formulaires similaires
• Toutes les étapes sont ordonnables/déclenchables à partir d’un évènement survenant lors du build
• Toutes les informations essentielles sont résumées en quelques écrans accessibles facilement dans un navigateur web
• L’ensemble est simple à comprendre. En une journée, nous obtenons une première définition de build qui récupère les sources au bon endroit, build et fait passer les tests
• Par défaut, on utilise les mêmes outils qu’utiliserait TFS (msbuild, mstest …) : aucune surprise donc
• TeamCity est riche de beaucoup de plugins. On peut faire beaucoup de choses avec et surtout on peut choisir de les installer ou pas
• Une installation simple : un installeur automatisé pour la version Windows
• Une architecture distribuée serveur/agent
• TeamCity fournit un build notifier à installer sur les postes des développeurs

Gestion des binaires avec TeamCity et NuGet

TeamCity intègre de manière très poussée le gestionnaire de packages NuGet. il existe 3 runner distincts :

• NuGet Installer : Installer et mettre à jour les packages NuGet requis pour builder votre projet sans avoir à les commiter dans le source control, ce qui a d’autant plus d’intérêt pour un DVCS. La configuration est simple, basée sur le .sln de la solution. Pour tous les builds, il est possible de voir quelle version des packages NuGet ont été embarqués.
• Nuget Pack : Créer (builder) ses propres packages NuGet, à partir de fichier .nuspec ou .csproj/.vbproj. La gestion de version est de la partie. Si vous ne voulez pas publier vos packages publiquement, il est possible d’utiliser TeamCity comme serveur NuGet natif. Dans ce cas, vous pouvez ajouter ce serveur comme source de packages dans Visual Studio.
• Nuget Publish : Publier les packages vers nuget.org (par défaut) ou alors sur un autre serveur NuGet. Il est nécessaire de fournir votre propre API key.

Exemple de stratégie de migration TFS vers Git/TeamCity

Pour une entreprise disposant de TFS et désirant migrer sa plateforme ALM, il est possible de faire cohabiter les deux UDD pendant un temps pour éviter une migration big-bang.

C’est là qu’intervient Git-TF. Initialement fournit par Microsoft, c'est un projet open-source, écrit en Java, permettant aux développeurs utilisant Git comme dépot local de partager leurs modifications avec TFS. Les commandes sont les mêmes que pour celles de type "git svn..." mais sont remplacées par "git tf...".

Ici, l’équipe 1, composée de développeurs .NET travaille avec Git en local. Leur code est pushé  vers le dépot Git Central. Sur ce serveur, Git-TF est installé. C’est un pont permettant les modifications d’être pushées depuis Git vers TFS, pour être mises à disposition de l’équipe 2.

De la même manière, si l’équipe 2 modifie le code source dans TFS, Git-TF ira les chercher pour les puller vers le dépot Central Git.

Ensuite, intervient l’addin TFS sur TeamCity, s’il détecte des modifications de code sur le dépot TFS, un build TeamCity est exécuté.

Dans cette configuration, il est possible de migrer équipe par équipe pour utiliser Git et TeamCity. L’ultime étape pour débrancher complètement TFS est de configurer TeamCity pour aller chercher les sources dans Git. A l’inverse, le coût d’un retour en arrière est presque nul et ne comporte aucun risque.

Quel est le coût ?

Le coût d’une usine de développement est un élément décisif, le prix des licences n’est pas le seul argument, il faut aussi prendre en compte le prix de son intégration et les éventuelles formations utilisateurs. Je vais les comparer à TFS comme point de repère.

(*) Gratuit jusqu’à 20 définitions de build Le coût d’intégration d’une UDD composée de Git et TeamCity ou TFS est globalement le même. Git nécessite un peu plus de configuration et compétences pour l’installer que TFS.

En partant de l’hypothèse que les développeurs ont déjà utilisé TFS, il n’est pas nécessaire de prévoir une formation. En revanche, elle est nécessaire pour Git et TeamCity.

La plus grande différence de coût réside dans les licences. Le modèle n’est pas du tout le même. Microsoft fait payer une CAL (Client Access License) par développeur, ce qui fait grimper la facture en même temps que l'augmentation du nombre de développeurs. JetBrains impose un coût d’entrée plus élevé certes, mais fixe et amorti à partir de 3 développeurs par rapport à TFS.

Conclusion

Plusieurs choix d’outils sont possibles pour une usine de développement .NET. Il me semble être pertinent d’opter pour celle correspondant pour le mieux au contexte et aux besoins des équipes projet. Je plaide pour une plus grande liberté dans le choix de l’UDD pour ces équipes.

Bien sûr, ce n’est pas gratuit, mais le jeu peut en valoir la chandelle s’il permet aux développeurs d’être plus efficaces.

Le principe du "Golden Hammer"  ("Si le seul outil dont vous disposez est un marteau : tout ressemble à un clou") ne s'applique pas plus dans le choix d’une plateforme ALM que pour tout autre sujet.