[Techdays 2013] Mise en place d’une usine logicielle pour technologies Microsoft et non Microsoft avec TFS 2012

download

Voici un retour sur la session intitulée « Mise en place d’une usine logicielle pour technologie Microsoft et non Microsoft avec TFS 2012 ». Cette session était animée par Guillaume Rouchon et Stéphane Barde. Elle résumait le travail fait concernant la migration des projets de la Mutuelle Générale sur TFS.

Elle a été découpée en trois parties : tout d’abord il a été question de gestion de sources, puis de build et enfin de déploiement automatique.

Le contexte

La mission était d’abord un test de mise en place de TFS dans un SI complexe.

Il faut savoir qu’à la Mutuelle Générale, ils ont à gérer des projets en .NET (toutes version depuis la 1.1), PHP, Java, COBOL, mais aussi des scripts PL/SQL, bash etc… Bref un SI composés de divers fichiers, aux langages totalement différents. Le but de la mission était de trouver des pistes pour fédérer tout cela dans un endroit unique, pouvoir en faire le suivi, etc…

La gestion du code source

Tout a commencé par les besoins exprimés par la Mutuelle Générale :

  • Une centralisation des sources
  • Une organisation des sources
  • Une stratégie de branching
  • Une intégration avec les outils existants

L’organisation à laquelle ils sont arrivés est de faire un Team Project par application métier et d’avoir une organisation pour chaque type de livrable ou techno. Enfin pour faciliter le partage de librairies, ils ont mis en place un serveur NuGet privé. Il est chargé de gérer les librairies externes ou internes.

Coté intégration aux outils, ils ont mis en place Team Explorer 2012 ou MSSCCI 2012 (Microsoft Source Code Control Interface) pour les projets un peu plus vieux. MSSCCI est disponible ici : http://visualstudiogallery.msdn.microsoft.com/b5b5053e-af34-4fa3-9098-aaa3f3f007cd

Pour l’intégration des outils non MS voici ce qui a été utilisé :

  • Java / PHP : TFS everywhere
  • SQL : Plugin VCS, Team explorer et le provider MSSCCI
  • Sur Linux : TFS everywhere

De plus, pour Linux, grâce aux “local workspaces” de TFS 2012, l’utilisation du gestionnaire de sources est transparente. Vous pourrez trouver TFS everywhere ici : http://www.microsoft.com/en-us/download/details.aspx?id=30661

Passons maintenant à leur intégration avec les builds.

Builds

Ah, les builds, pas d’intégration continue sans cette brique essentielle. Mais commençons par les besoins présentés lors de la session :

  • Versionning
  • Tests unitaires lancés automatiquement
  • Code Analysis
  • Packaging

 Environnement Microsoft

Pour commencer avec .NET 4, ils ont utilisés les Community TFS build extension  jumelées avec StyleCop pour la couche code analysis.

C’est pour la partie .NET 1.1 que cela se gâte. Il leur a fallu créer un template de build personnalisé pour diverses raisons. Premièrement, le projet ne supporte pas la compilation via MsBuild. Il leur a fallu encapsuler la compilation via devenv (Visual studio, oui, oui). Ensuite, pour les applications web, cela a nécessité d’utiliser les extensions FrontPage et la création à la volée d’une application web temporaire qui est supprimée à la fin du build. Là, en effet, c’est un peu plus compliqué.

Environnement Non Microsoft

Pour finir sur les outils Linux, ils ont fait pareil : des templates personnalisés. Ils font globalement trois choses : de la copie de fichiers source sur un serveur Linux, une invocation à distance de la compilation via ssh (et via putty) et enfin la récupération des fichiers compilés.

A mon avis, un grand effort a été déployé ici, mais une fois de plus, les templates de builds sont tellement modifiables qu’on peut en faire ce que l’on veut.

Déploiement automatique

Commençons comme pour les deux premières parties, avec les besoins. Ils voulaient être capables de déployer des applications :

  • Sur différents environnements
  • Sur des serveurs mutualisés
  • De manière paramétrable

Dans les deux cas, environnement Microsoft et non Microsoft, ils se sont appuyés sur le moteur de build pour le faire. Ils ont dû, dans les deux cas, développer des tâches de workflow spécialisées.

Ces workflows se lancent après les builds vus plus haut. Ils ont donc déjà à disposition des applications packagées qu’ils ont juste à récupérer. A partir de cela, sur les environnements MS, ils ont utilisé des tâches spécialisées pour déployer ou quand ce n’était pas possible, ils ont créé des scripts powershell invocables à distance. Dans le cas d’un déploiement sur environnement Linux, ils ont utilisé le même principe d’invocation à distance de scripts via ssh.

Conclusion

La plateforme TFS nous montre une fois de plus son ouverture et ses possibilités. Microsoft a travaillé d’arrache-pied pour fournir une plateforme flexible pouvant prendre en charge tout type de fichiers et de projets. J’ai beaucoup apprécié cette session car le SI était complexe à la base, de part ce mélange de langages, d’environnements ou de types de projets. Encore bravo aux speakers et merci pour ce retour d’expérience.

Nombre de vue : 69

AJOUTER UN COMMENTAIRE