Pour réinventer son application SRS de gestion des domaines, l’ Afnic s'est appuyé sur GitLab et SonarQube.

Dev

L’Afnic achève la rénovation de SRS, son application « coeur de métier »

Par Alain Clapaud, publié le 07 décembre 2022

L’Afnic gère depuis 25 ans les noms de domaines en « .fr ». C’est en quelque sorte le cerveau de l’Internet français. L’association achève un vaste projet de refactoring de son application SRS, un véritable ERP de la gestion de domaines.

Association loi de 1901, l’Afnic est en charge du registre des noms de domaines en « .fr ». C’est vers elle que convergent les demandes des Registrar, ces prestataires auprès desquels les entreprises ou les particuliers achètent leur nom de domaine. Le processus est automatisé et c’est l’application SRS (Shared Registry System) qui est sollicitée à chaque réservation de domaine.

Ce système a été développé il y a 25 ans, au moment de la mise en place du « .fr ». Il reposait alors essentiellement sur des scripts cgi développés en Perl, une technologie très en vogue en 1997… « Nous devions basculer sur une stack technique beaucoup plus moderne, notamment pour faire face à la pénurie de développeurs Perl, de moins en moins nombreux », explique Richard Coffre, chef de projet à l’Afnic. « S’appuyer sur cette plateforme n’était plus soutenable étant donné la croissance attendue dans les années à venir. »

Un vaste projet baptisé Avenir a été lancé il y a quatre ans pour redévelopper complètement SRS. Plutôt que d’opter pour une solution existante et la modifier pour l’adapter aux spécificités du marché français, l’Afnic a souhaité capitaliser sur son savoir-faire et créer une plateforme plus modulaire et plus extensible.

Ancien coach agile, Richard Coffre, recruté pour l’occasion, va lancer les développements en appliquant la méthode Scrum : « Nous avons démarré en full Scrum puis, comme c’est souvent le cas dans les gros projets, nous nous sommes dirigés vers une approche plus hybride de type Scrumban. »
En effet, les itérations très courtes de Scrum n’étaient pas bien adaptées à certaines portions de SRS.
« Nous avions besoin d’un tableau qui nous permette de visualiser tout ce que nous devons faire, typique du Kanban, et d’être dans une approche “juste à temps” vis-à-vis des différents jalons du projet. »
L’équipe projet se fait alors aider par Takima pour le volet Dev et par Octo Technology notamment sur le volet Ops.

À LIRE AUSSI :

GitLab au coeur de la chaîne CI/CD de l’Afnic

Outre l’aspect méthodologique, un point très structurant pour la réussite du projet fut la chaîne CI/CD mise en place pour porter les développements. Les développeurs se sont appuyés sur les outils classiques du monde Java, IntelliJ de JetBrains, tandis que la DSI exploite Confluence et Jira pour gérer son ticketing.

La nouvelle chaîne d’intégration continue repose sur GitLab et SonarQube pour le volet qualité du code produit, un aspect très important du projet. « Nous avons architecturé notre plateforme de production de code afin de privilégier au maximum l’automatisation. Le coeur de cette chaîne, c’est GitLab, qui assure la gestion très précise du code source produit. »

Richard Coffre,
chef de projet à l’Afnic

« L’atout majeur de GitLab dans notre contexte est d’avoir pu centraliser le code pour garantir son accès complet à l’équipe à tout moment. »

Le choix de GitLab a été notamment dicté par le dynamisme de la communauté des utilisateurs de la solution. En outre, au moment de ce choix en 2018, la nouvelle stack technique de SRS était à base de conteneurs logiciels. L’équipe projet a considéré que GitLab gérait mieux ce nouvel environnement de déploiement que ses concurrents. « Nous étions partis à l’origine sur la version communautaire gratuite, et lorsque le projet a pris de l’ampleur, nous avons réévalué notre choix et avons pris la décision de rester fidèles à GitLab qui a emporté l’adhésion de nos développeurs », ajoute le chef de projet.

En début du projet, tout le code n’était pas chargé sur GitLab. L’équipe a commencé par poster sur GitLab celui du backoffice de SRS, le front-office restant dans un projet annexe. Ce n’est qu’au bout de quelques mois, une fois tous les processus stabilisés, que tous les développements ont pu être centralisés sur GitLab dans une organisation de repository qui est le reflet de la montée en maturité de l’équipe. Richard Coffre souligne : « Tout le code est ainsi accessible, ce qui évite tout problème en cas de départ d’un développeur. En outre, c’est extrêmement utile pour le documenter et avoir une gestion précise des codes en erreur. »

Le recours massif à GitLab a permis à l’équipe projet de bien gérer ses branches de code, de bien l’étiqueter et de réaliser un versioning précis. L’objectif est de mutualiser au maximum alors que l’application SRS doit être personnalisée en fonction de l’extension de domaine. En effet, outre le « .fr », l’Afnic gère une quinzaine d’autres extensions et SRS doit être personnalisé pour chaque registre. GitLab permet de créer des branches de code spécifiques pour chacune de ces versions et permet d’éviter au maximum les duplications entre versions, source de surcoût et d’erreurs.

À LIRE AUSSI :

La révolution de l’« Infra as Code » en marche

Côté production, la nouvelle application SRS repose sur Kubernetes, avec des conteneurs Docker gérés dans un repository Harbor, mais le projet Avenir marque surtout l’avènement de l’approche « Infrastructure as Code » avec Ansible au sein de l’Afnic. « Ce fut un vrai changement de paradigme pour nous, reconnaît Richard Coffre. Nous nous reposions jusqu’à aujourd’hui sur une multitude de scripts. Avec ce projet, nous avons tout remis à plat et plongé dans l’approche “Infra as code”. Basculer une application du on-premise vers le cloud est aujourd’hui quasi transparent. Tout est centralisé sur GitLab et c’est le jour et la nuit en termes de capitalisation sur tout ce code lié à l’infrastructure ! »
Le rythme des mises en pré-production a pu s’accélérer, passant de deux par mois à trois par semaine aujourd’hui.

Les premiers déploiements ont eu lieu en mars 2020. 14 extensions ont pu être basculées sur le nouveau logiciel SRS ces 18 derniers mois, en commençant par les extensions « fermées », c’est-à-dire les extensions de marques qui comptent le moins de domaines (de l’ordre de 600 pour les plus petites à 60 000 pour le « .ovh »).

Reste à déployer la dernière des extensions gérées par l’Afnic, le « .fr » et ses quatre millions de domaines. Celle-ci doit être basculée en octobre 2022. L’application qui est actuellement utilisée par 50 à 60 bureaux d’enregistrement, va l’être par plus de 400 ! Une montée en charge que Richard Coffre attend sereinement : « Nous avons simulé en pré-production à plusieurs reprises la charge que représentent quatre millions de domaines. Cette montée en charge prochaine ne nous inquiète plus. »


LE PROJET EN CHIFFRES

12 développeurs en simultané, en pic, dans l’équipe projet, avec 4 testeurs et 3 Ops

500 000 nouvelles lignes de code produites

3 mises en pré-production par semaine


L’ENTREPRISE

Activité : Association loi 1901 en charge du « .fr »
Effectif : 90 collaborateurs
CA : 18 M€


À LIRE AUSSI :

Dans l'actualité