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

  1. 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

  1. Deploy › Production, sélectionnez le cluster.
  2. Trouvez l’application et comparez la version en cours à celle de la release.
  3. 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 :

  1. Vérifiez que vous détenez bien la permission de production pour cette action.
  2. Faites-le.
  3. 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.

  1. Deploy › Production, sélectionnez le cluster, trouvez le service.
  2. 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.
  3. 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.
  4. Si cela a commencé plus tard et indépendamment, c’est un problème d’exploitation. Utilisez Cluster Console pour inspecter directement le workload.
  5. 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