Le standard du travail, appliqué au mien

Pourquoi cette page#

Le service de développement demande à un acheteur de faire confiance à un standard. La preuve la plus honnête d'un standard est un travail que personne n'a commandé et que personne n'allait inspecter : cette page décrit donc le code derrière le produit d'avanserv et ce site. Le repository est privé, et ce qui suit en est tiré.

Ce que traverse chaque changement#

Aucun contrôle ne suffit à lui seul pour qu'un changement soit mergé. Un changement passe la vérification des types, le lint, les tests unitaires et de bout en bout, une recherche de secrets et de vulnérabilités connues, et un contrôle de rédaction qui tient les commentaires et la documentation à un style écrit. Chaque page publique est vérifiée au niveau WCAG 2.2 AA dans les deux thèmes, et publiée en deux langues, sans qu'aucune ne se replie sur l'autre. Le changement est ensuite relu : par un relecteur automatique sur chaque pull request, et par moi. Un contrôle en échec bloque le merge.

Comment il arrive en production#

L'infrastructure est du code, sur un hébergement européen, et chaque environnement est construit à partir de ce que dit le repository. Le chemin d'un merge à un environnement en service est écrit sous forme de procédures plutôt que retenu de mémoire, pour que quelqu'un d'autre que moi puisse le suivre.

Pour aller plus loin#

Le journal de développement en est la version longue. Trois articles couvrent le sujet de cette page en détail : le contrôle que passe chaque changement avant relecture, tenir le site au niveau WCAG 2.2 AA, et des environnements de recette construits depuis git.