À retenir
- Automatiser le chemin du commit à la production, tests compris.
- Garder la préproduction proche de la production et y déployer le même artefact.
- Rendre le retour arrière plus rapide qu'un correctif.
- Alerter sur les symptômes ressentis par les utilisateurs, pas sur chaque métrique.
Le DevOps n'est ni un outil ni un intitulé de poste. Un ensemble concret d'habitudes – pipelines, environnements, supervision et reprise – qui rendent les mises en production ennuyeuses, dans le bon sens du terme.
Un seul chemin automatisé vers la production
Chaque changement doit suivre le même chemin : build, tests, packaging, déploiement en préproduction, puis promotion du même artefact en production. Les étapes manuelles sont celles où les livraisons déraillent ; chacune que vous supprimez rend les déploiements plus sûrs.
- Lancer vérification de types, lint et tests à chaque pull request.
- Builder une fois ; promouvoir la même image ou le même bundle d'un environnement à l'autre.
- Exiger une revue avant la fusion dans la branche principale.
- Garder la configuration du pipeline dans le dépôt.
Des environnements identiques
Les bugs qui n'apparaissent qu'en production viennent généralement de différences entre environnements. Les conteneurs et l'infrastructure en code gardent préproduction et production semblables ; des données réalistes et anonymisées en préproduction attrapent le reste.
Livrer en sécurité, rétablir vite
Des livraisons petites et fréquentes sont plus faciles à comprendre et à annuler. Les migrations de base de données doivent être rétrocompatibles pour que la version précédente puisse encore tourner. Les feature flags permettent de livrer du code sans l'exposer tant qu'il n'est pas prêt.
Mesurez le temps nécessaire pour vous rétablir après une mauvaise livraison. Si le retour arrière prend plus de temps qu'un correctif, investissez dans le retour arrière.
Une supervision utile à 3 heures du matin
Alertez sur ce que vivent les utilisateurs – erreurs, réponses lentes, tâches en échec, pages indisponibles – plutôt que sur chaque pic de CPU. Chaque alerte doit être actionnable et adressée à quelqu'un qui peut agir.
- Contrôles de disponibilité sur les parcours utilisateurs clés.
- Suivi des erreurs avec marqueurs de version.
- Tableaux de bord de latence, taux d'erreur et profondeur des files.
- Des runbooks liés à chaque alerte.
La sécurité intégrée au pipeline
Analysez automatiquement les dépendances, conservez les secrets dans un coffre managé plutôt que dans le code ou les variables du pipeline, et ne donnez aux identifiants de déploiement que les droits dont ils ont besoin.
Cet article vous a plu ? Recevez le prochain par e-mail.