f(git) = production : l’équation du déploiement continu

Cette équation lapidaire, $f(\text{git}) = \text{production}$, capture l’essence du déploiement continu : le dépôt git est la source de vérité, et une fonction déterministe transforme son état en ce qui tourne en production.

Pas d’intervention manuelle, pas de serveur configuré à la main, pas de « je déploie depuis ma machine ». Un commit sur la branche principale déclenche une pipeline qui construit, teste et déploie automatiquement.

L’état du système en production est une fonction pure de l’état du repository. Cette correspondance biunivoque élimine toute une classe de problèmes :

• « ça marchait sur ma machine »
• « on a oublié de déployer ce fix »
• « personne ne sait quelle version tourne »

Le caractère fonctionnel

Le caractère fonctionnel de cette équation mérite qu’on s’y attarde.

Une fonction, au sens mathématique, est déterministe : les mêmes entrées produisent toujours les mêmes sorties. Si le pipeline de déploiement est vraiment une fonction de l’état de git, alors deux exécutions à partir du même commit doivent produire des artefacts identiques.

Cela exige :

• Des builds reproductibles : dépendances versionnées, pas de téléchargement implicite de « latest », timestamps neutralisés
• La configuration dans git, pas dans des variables d’environnement configurées manuellement sur le serveur
• L’infrastructure as code, les fichiers de configuration versionnés, les secrets gérés par des outils dédiés

Tout cela vise à faire entrer l’intégralité du système dans le domaine de cette fonction.

Git comme audit trail

Cette approche transforme git en audit trail exhaustif.

Qui a changé quoi, quand, pourquoi : chaque modification est tracée, chaque déploiement correspond à un commit identifiable.

• Le rollback devient trivial : on revient à un commit antérieur, la fonction s’applique, la production reflète cet état passé
• Le debugging en production gagne en clarté : on sait exactement quel code tourne, on peut le checkout localement, reproduire le contexte
• Les environnements de staging et de review deviennent des applications partielles de la même fonction sur des branches différentes

L’équation se généralise : $f(\text{branche}) = \text{environnement correspondant}$.

Corollaires organisationnels

Les corollaires organisationnels sont profonds.

Si $f(\text{git}) = \text{production}$, alors modifier la production exige de modifier git. Plus de changements ad hoc, plus de hotfix appliqués directement sur le serveur et oubliés.

Les opérations deviennent du code (scripts de migration, configurations Terraform, manifestes Kubernetes) revus et versionnés comme n’importe quel code applicatif.

La distinction entre développeurs et opérateurs s’estompe ; tous travaillent sur le même repository, soumis aux mêmes contraintes de qualité. Le pipeline devient le point de passage obligé, le goulot d’étranglement intentionnel où s’appliquent les vérifications automatisées.

Un idéal asymptotique

Cette équation est un idéal asymptotique plus qu’une réalité parfaitement atteinte :

• Les bases de données ont un état qui persiste entre les déploiements ; les migrations doivent être gérées avec soin
• Les dépendances externes (APIs tierces, services cloud) introduisent du non-déterminisme
• Les secrets ne peuvent pas toujours vivre dans git, même chiffrés

Mais tendre vers $f(\text{git}) = \text{production}$, réduire l’écart entre cet idéal et la pratique, c’est réduire l’incertitude, augmenter la reproductibilité, accélérer le feedback.

Chaque exception à cette équation (chaque configuration manuelle, chaque déploiement hors pipeline) est une dette à rembourser, une source potentielle de divergence entre ce que l’on croit avoir déployé et ce qui tourne réellement.