par

Si j’avais reçu 1 euro à chaque fois que j’ai entendu cette phrase, je pense que j’aurais résolu le problème du financement du Logiciel Libre…

Cette article se veut une introduction à la stack technique derrière Tuleap. Il a été écrit en priorité afin que les candidates et candidats au poste de développeuse / développeur backend puissent avoir une vision la plus précise possible de là ou ils mettent les pieds.

Du legacy mais pas que

Commençons par l’éléphant au milieu de la pièce : le Legacy. Du vrai, du genre qu’on ne sait pas dater précisément.

Selon les versions, la code base date de 2001 (date la plus ancienne dans le gestionnaire de version) ou 1999 (date des copyrights dans les fichiers). Ce code existe, il est parfois encore exécuté mais de façon assez anecdotique. La maintenance est assez légère car, grosso modo « ca tourne ». Notre stratégie est « on y touche pas sauf pour supprimer ». On retrouve du PHP « à la mode PHP3/PHP4 » mais aussi du Perl, un peu de python aussi.

Au rayon des choses compliquées à appréhender au début (et parfois pas qu’au début), c’est le choix de ne s’interdire aucun choix de design pour faire « au mieux des connaissances actuelles ». Les connaissances évoluant, il en résulte des architectures différentes d’un module (plugin) à l’autre, au point de se demander si tout a été écrit par la même équipe.

Le bon côté des choses c’est que l’on écrit pas du code en 2022 comme en 2001 « parce que ça a toujours été écrit comme ça ». Nous nous sommes autorisés à construire notre dernier gros plugin (Program Management, qui gère toute la partie SAFe) en Architecture Hexagonale. A côté de cela, certains plugins sont construits avec des fat controllers, god objects, de l’héritage à gogo, il faut savoir s’adapter.

La stack actuelle

Il en résulte qu’il peut être assez complexe pour un nouveau venu de savoir ce qui est attendu en terme d’architecture et choix techniques.

Depuis le printemps 2021, nous nous efforçons de garder trace des différentes évolutions sous forme d’Architecture Decision Record.

Tout n’y étant pas documenté, à l’automne 2022, le nouveau code Tuleap est attendu:

  • Avec des tests, idéalement écrits avant le code (TDD).
  • Suivant une approche RESTful.
  • La partie serveur écrite en PHP 8.0, avec Psalm pour l’analyse statique et PHPCS pour la vérification des règles de codage.
  • Pas d’utilisation de framework PHP ou d’ORM mais les briques pertinentes sont inclues via composer.
  • Le front end, HTML « classique » et Typescript lorsqu’il y a peu d’interactions riches avec l’utilisateur.
  • Si le fonctionnel client est plus complexe, utilisation de Vue3.
  • Tuleap vient avec un framework maison pour le rendu (TLP) et un thème associé (BurningParrot).
  • L’Intégration Continue et le Build sont des sujets centraux. La CI est orchestrée par Jenkins, nous faisons une grande utilisation de Nix pour garantir la reproductibilité de nos builds (et avoir des environnements de développement réellement identiques). Le Build front se repose sur pnpm, turbo et vite.

Disclaimer: cela veut dire qu’il faut aussi gérer les précédentes reco. C’est à dire gérer une grosse quantité code AngularJS (oui oui la v1.x), du jQuery, du Prototype js, du Vue2…

Sur ce Legacy, les tactiques sont multiples. Parfois on ré-écrit (mais c’est coûteux), parfois on supprime, parfois on grappille petit à petit. C’est un chantier de longue haleine.

Mais PHP au fait ?

Alors oui, la quasi totalité du backend est écrite en PHP. Est-ce que cela pose un problème ?

A part pour les gens qui ont en tête PHP = PHP4, ça n’en pose aucun. PHP 8+ avec l’utilisation de Psalm pour l’analyse statique permet d’avoir un langage suffisamment puissant pour résoudre l’ensemble des problèmes qui s’offrent à nous sans avoir à faire de concession sur l’élégance de la solution (Architecture Hexagonale, NeverThrow, etc). Si vous avez 1mn, vous pouvez jeter un coup d’œil aux évolutions du langage (sans même parler de l’outillage & de l’écosystème autour).

Sur les perspectives à moyen / long terme, nous réfléchissons à l’inclusion de WebAssembly. La cible prioritaire est de permettre du code « non Tuleap » (par exemple d’utilisateur finaux ou de développeurs d’extensions) mais, peut être trouverons nous d’autres cas d’usage.

Conclusion

Les chantiers techniques structurants de maintenance sont nombreux. Pour se donner une idée, les plus notables dans les prochains mois:

  • Le passage à MySQL 8.0, PHP 8.1 et 8.2, la prise en charge des versions récentes de RHEL
  • La première brique de la migration hors d’AngularJS
  • La prise en charge de WebAssembly