Staging

À quoi sert cet écran

Les environnements Staging sont partagés et persistants. C’est le premier palier où un changement rencontre quelque chose de réaliste — et le premier où le casser affecte d’autres personnes.

Avant de commencer

Pour faire ceci Il vous faut
Ouvrir la page env-by-branch.staging.access
Créer un environnement env-by-branch.staging.environment.create
Voir le flux d’événements env-by-branch.staging.event.read
Synchroniser une application env-by-branch.staging.application.sync
Redémarrer un deployment env-by-branch.staging.deployment.restart

Détenir la permission équivalente en dev n’accorde rien ici. Les paliers forment volontairement des familles de permissions distinctes.

Ouvrir l’écran

  1. Deploy › Staging dans la barre latérale.

URL directe : /ebb/staging

L’interface

Même mise en page que les autres paliers — voir Deploy. Ce qui est propre au staging :

📸 Capture d’écran : La page Staging Environments. Repères : (1) le sélecteur de cluster limité aux clusters de staging, (2) le sélecteur de système, (3) l’onglet Events.

Élément Comportement propre au staging
Sélecteur de cluster Ne propose que les clusters enregistrés comme clusters de staging
Environnements Partagés et persistants — pas de TTL, pas de nettoyage automatique
Events L’onglet le plus important ici, car d’autres personnes sont concernées

Procédures

Déployer un changement en staging

Nécessite env-by-branch.staging.application.sync.

  1. Deploy › Staging, sélectionnez le cluster et le système.
  2. Déployez le changement.
  3. Suivez l’onglet Events jusqu’au bout. Un déploiement vert signifie que la plateforme a fait son travail ; il ne dit rien du bon fonctionnement de l’application.

Redémarrer un deployment

Nécessite env-by-branch.staging.deployment.restart.

À utiliser quand l’application doit reprendre une configuration modifiée. N’oubliez pas que l’environnement est partagé : annoncez-le plutôt que de surprendre quelqu’un en plein test.

Scénario

« Le staging est cassé » et trois équipes sont bloquées.

Les environnements partagés transforment un problème en problème de tout le monde : la priorité est donc de découvrir ce qui a changé avant de changer quoi que ce soit d’autre.

  1. Deploy › Staging, sélectionnez le cluster.
  2. Ouvrez l’onglet Events et remontez depuis le plus récent. Vous cherchez la première défaillance, pas la plus bruyante.
  3. Identifiez l’application en échec et descendez-y via Détail d’un environnement.
  4. Vérifiez si un déploiement a eu lieu juste avant la défaillance. Si oui, le geste sûr le plus rapide est généralement de revenir sur ce changement plutôt que de le déboguer en direct pendant que trois équipes attendent.
  5. Si le changement provenait d’une release, coordonnez-vous via Déploiements plutôt que d’agir directement sur l’environnement, sinon l’enregistrement de la release et la réalité divergent.
  6. Une fois rétabli, reproduisez le problème sur un environnement de dev, où vous pourrez prendre votre temps.

L’étape 6 est ce qui évite la récidive. Réparer le staging sous pression n’apprend rien à personne.

En cas de problème

Symptôme Cause Comment vérifier Solution
Vous voyez Dev mais pas Staging Les paliers sont des permissions distinctes Access Explorer Demandez env-by-branch.staging.access
Aucun cluster listé Aucun cluster enregistré comme staging, ou aucun valide Clusters Enregistrez-en un et validez-le
Le déploiement réussit, l’application est erronée La réussite d’une synchronisation n’est pas la santé de l’application L’onglet Events, puis la ressource Diagnostiquez l’application
Le changement de quelqu’un d’autre est apparu Le staging est partagé L’onglet Events Coordonnez-vous via Déploiements
Impossible de redémarrer un deployment Il manque env-by-branch.staging.deployment.restart Access Explorer Demandez-la sur le palier staging

Pour aller plus loin

  • Production — le dernier palier
  • Revue Helm — examinez les changements de chart avant qu’ils n’y arrivent