Exigences, gestion de versions, tests, livraison et parcours d’une requête

D’une idée à une exigence

Un logiciel commence par un besoin : un restaurant veut prendre des commandes en ligne, un hôpital veut que les patients prennent eux-mêmes leurs rendez-vous. Transformer ce besoin en quelque chose qu’une équipe peut construire, c’est le travail des exigences. Certaines exigences décrivent ce que le système doit faire (« un client peut payer par carte ») ; d’autres décrivent avec quel niveau de qualité il doit le faire (« le paiement se termine en moins de deux secondes pour 95 % des clients »). Le chapitre 2 montre que la seconde catégorie, les attributs de qualité, guide la plupart des décisions d’architecture.

Beaucoup d’équipes saisissent les besoins fonctionnels sous forme de récits utilisateur (user stories) : de courtes descriptions écrites du point de vue de l’utilisateur. Kent Beck les a introduits dans l’Extreme Programming à la fin des années 1990, et une équipe de l’entreprise londonienne Connextra a conçu en 2001 le modèle que la plupart des gens utilisent aujourd’hui :

As a hungry customer,
I want to reorder a meal I have ordered before,
so that I can eat sooner without searching the menu again.

Acceptance criteria
- My last 10 orders appear on the home screen.
- Tapping "Reorder" fills the basket with the same items.
- Items that are no longer available are flagged, not silently dropped.

Un récit est volontairement court et incomplet. Ron Jeffries le décrivait comme une carte, une conversation et une confirmation : la carte sert d’aide-mémoire, les détails se règlent en conversation entre les personnes qui veulent la fonctionnalité et celles qui la construisent, et les critères d’acceptation confirment quand elle est terminée. Les praticiens ne sont pas d’accord sur ce qu’il faut écrire à l’avance. Les équipes des secteurs réglementés, comme les dispositifs médicaux et l’aéronautique, doivent tenir des exigences formelles et traçables ; les équipes produit préfèrent souvent des récits plus légers, affinés juste avant le début du travail. Les deux approches sont légitimes dans leur contexte.

La gestion de versions avec Git

Le code source est le document partagé le plus précieux de l’équipe, et de nombreuses personnes le modifient chaque jour. La gestion de versions enregistre chaque modification, qui l’a faite et pourquoi, permet de travailler en parallèle sans écraser le travail des autres, et permet de restaurer n’importe quel état antérieur. Presque toutes les équipes utilisent aujourd’hui Git, créé par Linus Torvalds en 2005 pour le développement du noyau Linux, généralement avec un service d’hébergement comme GitHub, GitLab ou Bitbucket.

Quelques notions couvrent l’essentiel de l’usage quotidien. Un commit est un instantané enregistré d’un ensemble de modifications, accompagné d’un message qui l’explique (« Ajouter un bouton de pourboire au paiement »). Une branche est une ligne de travail séparée : un développeur crée une branche à partir de main, y fait des commits sans déranger personne et, une fois terminé, fusionne (merge) sa branche dans la ligne principale, ce qui combine les deux historiques. Si deux personnes ont modifié les mêmes lignes, Git signale un conflit de fusion qu’un humain doit résoudre.

Sur les services d’hébergement, la fusion passe généralement par une pull request (GitLab parle de merge request) : une page web qui présente la modification proposée, où des vérifications automatisées s’exécutent et où des collègues effectuent une revue de code, en lisant la modification, en posant des questions et en suggérant des améliorations avant de l’approuver. La revue détecte des défauts, mais ses bénéfices les plus importants sont la diffusion des connaissances (au moins deux personnes comprennent chaque modification) et la cohérence de la conception. Les architectes participent souvent à la revue des modifications qui touchent la structure ou les interfaces.

git switch -c feature/tip-button     # create a branch and move onto it
# ... edit files ...
git add checkout.py test_checkout.py
git commit -m "Add tip button to checkout"
git push -u origin feature/tip-button  # upload; then open a pull request
# after review and green checks, the branch is merged into main

Les équipes divergent sur la gestion des branches. Certaines gardent des branches de longue durée par fonctionnalité ou par version ; d’autres pratiquent le trunk-based development (développement basé sur le tronc), en fusionnant de petites modifications dans main au moins une fois par jour et en masquant les fonctionnalités inachevées derrière des interrupteurs appelés feature flags. Les recherches du programme DORA associent les branches de courte durée à de meilleures performances de livraison, mais le bon choix dépend aussi de la manière dont l’équipe met en production.

Les tests : la pyramide

Toute modification risque de casser quelque chose qui fonctionnait, ce qu’on appelle une régression. Les tests automatisés sont des programmes qui vérifient d’autres programmes : on peut donc les lancer à chaque modification en quelques minutes, au lieu de confier la vérification à des personnes pendant des jours. Ils se présentent en couches. Un test unitaire vérifie un petit élément, comme une fonction, de façon isolée, et s’exécute en quelques millisecondes. Un test d’intégration vérifie que des parties fonctionnent ensemble : le code des commandes avec une vraie base de données, ou la boutique avec l’environnement de test d’un prestataire de paiement. Un test de bout en bout pilote le système entier comme le ferait un utilisateur, par exemple en parcourant l’app de la carte jusqu’à la confirmation de commande.

La pyramide des tests de Mike Cohn, publiée dans son livre de 2009 Succeeding with Agile, suggère les proportions : beaucoup de tests unitaires, moins de tests d’intégration et peu de tests de bout en bout. Les couches supérieures sont plus réalistes, mais plus lentes, plus coûteuses à maintenir et plus sujettes aux échecs instables (flaky), qui apparaissent et disparaissent pour des raisons sans rapport avec la modification. Certains praticiens défendent une autre forme, par exemple davantage de tests d’intégration pour les systèmes qui servent surtout de liant entre des services ; le principe sur lequel tous s’accordent est de détecter la plupart des problèmes avec des tests rapides, fiables et ciblés.

def delivery_fee(basket_total, distance_km):
    if basket_total >= 25:
        return 0.0                      # free delivery on larger orders
    return round(1.50 + 0.40 * distance_km, 2)

def test_free_delivery_over_threshold():
    assert delivery_fee(30.00, 5) == 0.0

def test_fee_grows_with_distance():
    assert delivery_fee(10.00, 5) == 3.50

Les environnements : du développement à la production

Le code traverse plusieurs environnements sur le chemin qui le mène aux clients, chacun étant une copie séparée du système avec ses propres serveurs, données et réglages. Le but est de trouver les problèmes là où ils sont peu coûteux et sans danger, avant qu’ils n’atteignent la production, l’environnement réel dont dépendent les vrais utilisateurs.

Plus les environnements diffèrent de la production, plus les problèmes passent entre les mailles : une base de test de cent lignes ne révélera pas l’index manquant qui fait durer une requête quarante secondes face à dix millions de lignes. Il est plus facile de garder des environnements semblables quand ils sont construits à partir des mêmes images de conteneur et de la même configuration scriptée, un thème de l’infrastructure en tant que code.

Intégration, livraison et déploiement continus

L’intégration continue (CI) est la pratique qui consiste à fusionner fréquemment, au moins une fois par jour, le travail de chacun dans la ligne principale partagée, un build et des tests automatisés vérifiant chaque modification. Elle est née de l’Extreme Programming dans les années 1990. Son intérêt est que les problèmes d’intégration sont détectés en quelques minutes, tant que la modification est fraîche dans l’esprit de son auteur, au lieu de l’être lors d’une pénible « phase d’intégration » des semaines plus tard. Une équipe qui pratique la CI traite un build en échec comme une urgence : le réparer passe avant tout nouveau travail.

La livraison continue (CD) prolonge la CI pour que le logiciel soit toujours prêt à être mis en production : chaque modification qui passe le pipeline pourrait être mise en production d’une simple pression sur un bouton, et la mise en production devient une décision métier de routine plutôt qu’un événement risqué. L’approche a été exposée par Jez Humble et David Farley dans leur livre de 2010 Continuous Delivery. Le déploiement continu va un cran plus loin et met automatiquement en production chaque modification qui passe le pipeline, sans approbation humaine ; les équipes qui le pratiquent peuvent déployer de nombreuses fois par jour.

L’automatisation qui achemine une modification du commit jusqu’à la production est un pipeline. Comme chaque étape est automatisée et identique à chaque fois, les mises en production cessent de dépendre d’une personne qui doit se souvenir d’une liste de contrôle à minuit.

Façons de travailler : cycle en cascade, Scrum et Kanban

Les équipes choisissent aussi comment organiser le travail lui-même. Dans une approche séquentielle, souvent appelée cycle en cascade (waterfall), le projet traverse des phases dans l’ordre : exigences, conception, implémentation, tests, déploiement. Chaque phase se termine avant que la suivante commence. Le nom est généralement attribué à l’article de Winston Royce de 1970, bien que Royce n’ait pas employé ce mot et qu’il ait en fait averti qu’un passage unique à travers les phases était risqué. Les plans séquentiels conviennent encore aux travaux dont les exigences sont figées et où le changement coûte très cher, comme certains projets réglementés ou dépendants du matériel. Leur faiblesse, pour la plupart des logiciels, est que les utilisateurs ne voient rien avant un stade tardif : les malentendus apparaissent donc quand ils coûtent le plus cher à corriger.

Les approches agiles, nommées dans le Manifeste agile de 2001, livrent un logiciel qui fonctionne par cycles courts et ajustent les plans à mesure qu’elles apprennent. Scrum est le cadre le plus utilisé : une petite équipe travaille par cycles fixes appelés sprints, d’un mois ou moins, chacun commençant par une planification et se terminant par une revue du travail et une rétrospective sur la façon dont l’équipe a travaillé. Le Guide Scrum de 2020 définit trois responsabilités : le Product Owner (qui décide de ce qui a le plus de valeur), le Scrum Master (qui aide l’équipe à utiliser Scrum efficacement) et les Developers (qui font le travail). Kanban, adapté au logiciel à partir du système de production de Toyota, n’a pas de cycles fixes : les éléments de travail circulent sur un tableau visible (à faire, en cours, en revue, terminé), et l’équipe limite le nombre d’éléments en cours à un moment donné, afin que le travail soit terminé avant d’en commencer davantage.

Aucune de ces approches ne convient à toutes les équipes, et beaucoup d’organisations les combinent : Scrum pour les équipes produit, Kanban pour le support et l’exploitation, un plan plus séquentiel autour d’une échéance réglementaire fixe. Qualifier un processus d’« agile » ne le rend pas agile ; ce qui compte, c’est qu’un logiciel qui fonctionne parvienne à de vrais utilisateurs assez souvent pour apprendre d’eux.

DevOps : une seule équipe responsable, du code jusqu’au client

Traditionnellement, les développeurs écrivaient le logiciel et une équipe d’exploitation distincte le faisait tourner, avec des incitations contradictoires : les développeurs étaient récompensés pour le changement, l’exploitation pour la stabilité. Le DevOps est le mouvement, baptisé lors de la première conférence DevOpsDays à Gand en 2009, qui réunit les deux. C’est avant tout une culture de responsabilité partagée (« you build it, you run it » : vous le construisez, vous l’exploitez), soutenue par des pratiques comme le CI/CD, l’infrastructure en tant que code, la supervision et les revues d’incidents sans recherche de coupable. Ce n’est ni un intitulé de poste ni un outil, même si l’on vend les deux sous ce nom. Le programme de recherche DORA est surtout connu pour mesurer la performance de livraison avec quatre indicateurs clés : la fréquence de déploiement d’une équipe, le temps qu’une modification met à atteindre la production, la fréquence des échecs des modifications et la rapidité du rétablissement du service après une défaillance.

Exemple commenté : le parcours d’un simple appui

Tout ce chapitre se rejoint en un seul instant. Un client a rempli un panier dans une app de livraison de repas et appuie sur Commander. En une seconde ou deux, l’écran affiche « Commande confirmée », et vingt minutes plus tard le téléphone vibre : « Votre livreur est en route ». Voici ce qui se passe, étape par étape, avec la notion derrière chaque étape et l’endroit où elle a été présentée.

Pourquoi c’est important pour l’architecture

Le parcours d’un simple appui mobilise une douzaine de composants, trois organisations et des communications à la fois synchrones et asynchrones, et il a bien fallu le concevoir : quelqu’un a décidé que le paiement est synchrone et que les notifications ne le sont pas, que les commandes résident dans une base de données relationnelle, que le service tourne dans des conteneurs sur deux zones, que le prestataire de paiement est isolé derrière un seul module. Décider de l’agencement de ces parties, des qualités qu’atteint chaque agencement et de ce qu’il coûte, et consigner pourquoi, c’est l’architecture logicielle. La manière dont le logiciel est construit compte aussi pour l’architecture : une architecture qu’on ne peut pas tester par morceaux, ni mettre en production sans coordonner dix équipes, ralentit chaque modification. Le chapitre 1 commence par ce qu’est l’architecture logicielle.