Depuis quelques mois, on colle DevOps sur pas mal tout. Un serveur de build automatise la compilation; il ne rend pas automatiquement l’application observable, récupérable ni partageable entre développement et exploitation. La boucle complète va du commit au comportement en production, puis revient vers l’équipe.

Un changement traverse source, build, tests, artefact, configuration, déploiement, métriques et parfois rollback. Chaque étape doit produire une preuve et réutiliser le même artefact. Recompiler entre test et production crée une différence qu’on ne peut plus expliquer.

Une livraison minimale reproductible

Le pipeline pourrait :

1. récupérer un commit identifié;
2. compiler et exécuter les tests unitaires;
3. analyser dépendances et configuration;
4. produire un paquet versionné et immuable;
5. déployer dans un environnement de test;
6. exécuter tests d’intégration et de sécurité;
7. promouvoir le même paquet;
8. vérifier une sonde fonctionnelle après déploiement.

La configuration spécifique reste hors du paquet et ses changements sont audités. Les secrets viennent d’un magasin contrôlé. Un déploiement en deux groupes réduit le rayon : une petite part reçoit la version, les métriques sont comparées, puis la suite avance ou revient.

Le rollback technique n’est pas toujours un retour métier. Si la nouvelle version migre les données ou envoie des factures, remettre le vieux binaire ne défait pas ces actions. Les migrations doivent rester compatibles pendant la transition et les opérations externes posséder une compensation.

L’exploitation fournit les critères de conception

Les logs structurés, métriques et identifiants de corrélation sont développés avec la fonction. Une alerte porte sur erreur utilisateur, latence ou file bloquée, avec un runbook et un propriétaire. Une alerte sans action connue devient du bruit; aucune alerte laisse le client faire le monitoring.

Les développeurs participent aux incidents afin de voir le comportement réel; l’exploitation participe tôt au design afin de signaler certificats, capacité et reprise. Le but n’est pas que tout le monde possède tous les accès. Les rôles privilégiés restent séparés, temporaires et audités.

Je suivrais fréquence de livraison, délai de changement, taux d’échec et temps de restauration. Accélérer les builds tout en augmentant les incidents n’est pas un progrès. Un exercice où on casse une dépendance et restaure un service teste mieux la collaboration qu’un nouvel intitulé.

Concevoir le changement de base en deux temps

Une application et son schéma ne basculent pas toujours ensemble. Pour renommer une colonne, j’ajouterais d’abord la nouvelle, écrirais temporairement dans les deux et déploierais les lecteurs compatibles. Un job copie l’historique avec compteurs et reprise. Après vérification que plus aucun consommateur ne lit l’ancienne, une livraison ultérieure la retire. Cette stratégie expand-contract accepte une période de duplication pour éviter une panne coordonnée. Le pipeline teste les deux versions pendant la transition et surveille les divergences. Elle montre bien pourquoi la livraison continue exige du design dans le code et les données, pas seulement un bouton automatique.

Ma pratique serait de choisir une application, automatiser un chemin jusqu’à production, puis remettre chaque signal et étape de reprise à l’équipe qui livre. DevOps devient concret lorsque le même groupe peut expliquer ce qui roule, détecter ce qui va mal et remettre la dernière version saine sans improviser.