Production
À quoi sert cet écran
Les environnements Production sont persistants et pilotés par le Release Manager. C’est la différence essentielle avec les autres paliers : on ne pousse pas en production comme on pousse en dev. Les changements y arrivent par une release.
Avant de commencer
| Pour faire ceci | Il vous faut |
|---|---|
| Ouvrir la page | env-by-branch.production.access |
| Créer un environnement | env-by-branch.production.environment.create |
| Voir le flux d’événements | env-by-branch.production.event.read |
| Synchroniser une application | env-by-branch.production.application.sync |
| Redémarrer un deployment | env-by-branch.production.deployment.restart |
Accordez-les délibérément et étroitement. Une policy qui oublie sa condition d’environnement accorde la production en même temps que le dev, et les deux sont visuellement identiques dans la liste des policies.
Ouvrir l’écran
- Deploy › Production dans la barre latérale.
URL directe : /ebb/production
L’interface
Même mise en page que les autres paliers — voir Deploy. Ce qui est propre à la production :
📸 Capture d’écran : La page Production Environments. Repères : (1) le sélecteur de cluster limité aux clusters de production, (2) une ligne d’environnement, (3) l’onglet Events.
| Élément | Comportement propre à la production |
|---|---|
| Sélecteur de cluster | Ne propose que les clusters enregistrés comme clusters de production |
| Environnements | Persistants, pilotés par le Release Manager plutôt que par des déploiements ponctuels |
| Events | Votre trace de ce qui s’est réellement passé, et quand |
Procédures
Vérifier qu’une release est arrivée en production
- Deploy › Production, sélectionnez le cluster.
- Trouvez l’application et comparez la version en cours à celle de la release.
- Ouvrez l’onglet Events pour voir le déploiement se poser, et repérer ce qui aurait échoué après un déploiement vert.
Agir directement sur un environnement de production
Il le faut parfois — un redémarrage ou une synchronisation urgente. Dans ce cas :
- Vérifiez que vous détenez bien la permission de production pour cette action.
- Faites-le.
- Retournez dans Déploiements et consignez ce que vous avez fait. Une action directe laisse l’enregistrement de la release décrire une réalité périmée, et la personne suivante fera confiance à cet enregistrement.
Scénario
Une release est en ligne et un service renvoie des erreurs.
- Deploy › Production, sélectionnez le cluster, trouvez le service.
- Onglet Events. Déterminez quand cela a commencé, et si cela coïncide avec la pose de la release. Ce seul fait détermine toute la suite.
- Si cela a commencé avec la release, c’est un problème de release : allez dans Déploiements › Releases et suivez votre procédure de retour arrière, afin que l’enregistrement reste exact.
- Si cela a commencé plus tard et indépendamment, c’est un problème d’exploitation. Utilisez Cluster Console pour inspecter directement le workload.
- Dans les deux cas, une fois la situation stabilisée, consultez Analytics : l’analyse des échecs transforme cet incident en quelque chose de comparable au précédent.
La distinction de l’étape 2 constitue tout le scénario. Revenir sur une release qui n’était pas en cause remplace une panne par deux.
En cas de problème
| Symptôme | Cause | Comment vérifier | Solution |
|---|---|---|---|
| Production n’est pas dans le sous-menu | Il vous manque env-by-branch.production.access |
Access Explorer | Demandez un rôle cantonné à la production — délibérément |
| Un utilisateur atteint la production sans devoir | Un statement de policy sans condition d’environnement | Les statements de la policy | Ajoutez la condition ; voir Policies |
| Aucun cluster listé | Aucun cluster enregistré comme production, ou aucun valide | Clusters | Enregistrez-en un et validez-le |
| L’environnement ne correspond pas à la release | Quelqu’un a agi directement sur l’environnement | L’onglet Events | Réconciliez via Déploiements |
| Vous pouvez agir en staging mais pas en production | Familles de permissions distinctes par palier | Access Explorer | Comportement attendu — demandez explicitement si c’est réellement nécessaire |
Pour aller plus loin
- Déploiements › Releases — comment les changements arrivent ici
- Analytics — ce que les déploiements donnent dans la durée