Déploiements

À quoi sert cet écran

Deployments — le Release Manager — est la façon dont les changements atteignent la production tout en restant justifiables après coup. Une release regroupe les composants qui partent ensemble, consigne ce qu’elle contient, recueille les validations et pilote le runbook qui l’exécute.

Si Dev et Staging sont les endroits où l’on découvre si un changement fonctionne, c’est ici que l’on décide qu’il part en production et que l’on en garde la trace.

Avant de commencer

Pour faire ceci Il vous faut
Ouvrir la zone deployment-manager.access
Créer une release deployment-manager.release.create
Ouvrir le détail d’une release deployment-manager.release.view.details
Utiliser les actions rapides deployment-manager.release.view.details.quick-actions
Valider une release deployment-manager.release.signoff
Supprimer une release deployment-manager.release.delete
Supprimer n’importe quelle release deployment-manager.release.admin-delete
Modifier la configuration deployment-manager.config.<zone> — une par onglet

Les permissions de configuration sont volontairement granulaires : config.jira, config.environments, config.signoff-roles, config.notifications, config.release-notes-template, config.tag-patterns, config.general. Vous pouvez confier les notifications à quelqu’un sans lui permettre de modifier les règles de validation.

Ouvrir l’écran

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

URL directe : /deployment-manager

L’interface

📸 Capture d’écran : Le tableau de bord Deployments. Repères : (1) la liste des releases, (2) l’action de création, (3) le lien vers la configuration.

Page Route Traitée dans
Tableau de bord /deployment-manager Cette page
Releases /deployment-manager/releases Releases
Créer une release /deployment-manager/releases/create Releases
Détail d’une release /deployment-manager/releases/:id Releases
Runbook MEP /deployment-manager/mep/:releaseId Runbook MEP
Configuration /deployment-manager/configuration Configuration

Procédures

Sur une installation neuve, procédez dans cet ordre :

  1. Configuration — environnements, rôles de validation, motifs de tags et modèle de notes de release. Une release créée avant que tout cela existe n’hérite de rien de sensé.
  2. Releases — créez la release.
  3. Runbook MEP — exécutez-la.

Scénario

Votre première release sur une installation neuve.

  1. Configuration › Environments — déclarez les environnements qu’une release peut viser, et les clusters autorisés pour chacun.
  2. Configuration › Release Sign-offs — décidez qui doit approuver. Le faire avant la première release est bien plus simple que de greffer une validation sur un processus dont les gens ont déjà pris les habitudes.
  3. Configuration › Release Notes Template — définissez le modèle, pour que chaque release se décrive de la même façon.
  4. Releases — déroulez l’assistant de création.
  5. Runbook MEP — exécutez la release et suivez-la jusqu’au bout.
  6. Production — vérifiez que l’environnement la reflète.

Sauter l’étape 2 est le raccourci classique, et c’est celui qui transforme l’enregistrement de release, d’une piste d’audit, en simple journal intime.

En cas de problème

Symptôme Cause Comment vérifier Solution
Deployments n’est pas dans le sous-menu Il manque deployment-manager.access Access Explorer Demandez un rôle qui l’accorde
Vous voyez les releases mais ne pouvez pas en ouvrir access sans release.view.details Access Explorer Demandez la permission de détail
Impossible de créer une release Il manque deployment-manager.release.create Access Explorer Demandez-la
Un onglet de configuration est en lecture seule Les permissions de configuration sont par zone Access Explorer Demandez la permission config.<zone> correspondante
La production ne correspond pas à une release Quelqu’un a agi directement sur l’environnement L’onglet Events de Production Réconciliez ici pour que l’enregistrement reste exact

Pour aller plus loin