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.