06 / 07Déployer
Changements revus. Environnements reproductibles. Déploiements contrôlés et procédures de reprise.
Déployer, c’est le chemin que suit un changement, du développeur à votre système de production. Nous gardons ce chemin dans Git, revu et reproductible.
- Revoir
- Construire
- Déployer
- Observer
Plan des services
Quand vous en avez besoin
- Les changements se font directement en production, et personne ne peut dire ce qui a changé la semaine dernière.
- Un correctif fonctionne en test et échoue en production, parce que les deux environnements diffèrent.
- Une seule personne sait comment déployer.
- Après une mise en production ratée, aucun retour arrière n’est convenu.
- Un nouveau CTO ou un auditeur demande qui a approuvé un changement, et il n’en existe aucune trace.
Plateforme
Déployer.
Un nouveau rapport, une intégration réparée, une montée de version : chaque changement doit arriver en production sans perturber ce qui fonctionne déjà.
Un dépôt Git contient l’état cible du système : le code, la configuration et la description des environnements. Chaque changement y est revu, et les environnements sont construits à partir de lui.
Le résultat est un environnement que l’on peut reproduire, et non un environnement dont quelqu’un doit se souvenir.
Ce que nous faisons
- GitOps : Git comme source de l’état cible, avec des changements revus avant d’être fusionnés.
- Environnements reproductibles pour le développement, la préproduction et la production.
- CI/CD pour la construction et le déploiement.
- Déploiements contrôlés, avec une procédure de reprise.
- Conteneurs, et Kubernetes lorsque c’est pertinent.
- Observabilité, pour que l’effet d’une mise en production soit visible.
Comment cela s’articule
Le moment où un changement entre en production est une décision métier. Une mise en production en pleine clôture mensuelle ou pendant la semaine d’expédition la plus chargée est un risque dont personne n’a besoin. Le calendrier appartient donc à ceux qui dirigent ces domaines. Ces domaines figurent sur la page Odoo.
Les changements réalisés sur la couche application empruntent ce chemin. Une personnalisation vient de Construire & personnaliser, une intégration de Connecter, un flux de travail d’Automatiser, une nouvelle version de Migrer & mettre à niveau.
Sur la couche plateforme, les environnements où un changement est déployé sont pris en charge par Exploiter. Un système où les changements se font depuis longtemps à la main en production est un cas pour Sauver.
Quand vous en avez besoin
- Les changements se font directement en production, et personne ne peut dire ce qui a changé la semaine dernière.
- Un correctif fonctionne en test et échoue en production, parce que les deux environnements diffèrent.
- Une seule personne sait comment déployer.
- Après une mise en production ratée, aucun retour arrière n’est convenu.
- Un nouveau CTO ou un auditeur demande qui a approuvé un changement, et il n’en existe aucune trace.
Dites-nous comment un changement arrive en production chez vous aujourd’hui.