Releases
À quoi sert cet écran
Une release est un ensemble de composants partant ensemble vers un environnement, avec ses notes, les travaux qui lui sont rattachés, ses approbations et son historique d’exécution au même endroit.
Avant de commencer
| Pour faire ceci | Il vous faut |
|---|---|
| Voir les releases | deployment-manager.access |
| En ouvrir une | deployment-manager.release.view.details |
| En créer une | deployment-manager.release.create |
| Utiliser les actions rapides | deployment-manager.release.view.details.quick-actions |
| En valider une | deployment-manager.release.signoff |
| Supprimer les vôtres | deployment-manager.release.delete |
| Supprimer celles des autres | deployment-manager.release.admin-delete |
Configurez d’abord les environnements et les rôles de validation — voir Configuration.
Ouvrir l’écran
- Liste :
/deployment-manager/releases - Création :
/deployment-manager/releases/create - Une release :
/deployment-manager/releases/:id
L’interface
📸 Capture d’écran : Une page de détail de release sur l’onglet Overview. Repères : (1) la barre d’onglets, (2) le statut de la release, (3) les actions rapides, (4) le lien vers le runbook MEP.
Le détail d’une release comporte jusqu’à sept onglets :
| Onglet | Ce qu’il montre |
|---|---|
| Overview | Statut, cible et contenu de la release |
| Requests | Les demandes de changement de la release |
| Release Notes | Les notes, issues de votre modèle |
| Pull Requests | Les PR liées — uniquement si l’intégration est activée |
| Jira Issues | Les tickets liés — uniquement si Jira est connecté |
| Deployments | Ce qui a été déployé, et où |
| Execution History | Les exécutions du runbook — même contenu que Runbook MEP |
| Full Timeline | Tout, dans l’ordre |
Les onglets Pull Requests et Jira Issues sont absents tant que ces intégrations ne sont pas configurées. Leur absence est un état de configuration, pas un problème de permission — voir Settings › Development › Integrations.
L’assistant de création
| Étape | Ce qu’elle fait | Présente quand |
|---|---|---|
| Select System | Choisit le système, ainsi que la version et le nom de la release | Toujours — les étapes suivantes s’appuient dessus |
| Jira Integration | Rattache des tickets Jira | Uniquement si Jira est activé |
| Configure Components | Choisit les composants et leur type de CI (par ex. Argo Workflows) | Toujours |
| Release Notes | Renseigne les notes | Toujours |
| Review & Create | Vérification finale | Toujours |
Procédures
Créer une release
Nécessite deployment-manager.release.create.
- Deploy › Deployments › Releases, cliquez sur créer.
- Select System — choisissez le système, puis fixez la version et le nom. Soignez cette étape : toutes les suivantes s’appuient dessus.
- Jira Integration, si affichée — sélectionnez les tickets. Si le système n’a pas de projet Jira configuré, l’étape le signale et vous pouvez continuer sans.
- Configure Components — choisissez ce qui part et confirmez le type de CI de chaque composant.
- Release Notes — remplissez-les à partir du modèle.
- Review & Create.
Valider une release
Nécessite deployment-manager.release.signoff.
Ouvrez la release et validez. Qui doit valider se définit dans Configuration › Release Sign-offs.
Supprimer une release
release.delete couvre les vôtres. Supprimer celle d’un autre exige
release.admin-delete — une permission volontairement distincte, car supprimer
une release détruit la trace de ce qui est parti.
Scénario
Une release est à moitié exécutée et quelqu’un demande « qu’est-ce qui est réellement parti ? »
C’est précisément à cela que sert l’enregistrement : résistez à l’envie d’inspecter le cluster d’abord.
- Ouvrez la release. Overview vous donne le statut et la cible.
- Onglet Deployments — ce qui a été déployé et où. C’est la réponse faisant autorité à la question posée.
- Execution History — jusqu’où le runbook est allé, et où il s’est arrêté.
- Full Timeline — la séquence, y compris ce qui a été fait hors procédure.
- Ce n’est qu’alors que vous comparez à la réalité dans l’onglet Events de Production. En cas de divergence, quelqu’un a agi directement sur l’environnement, et cet écart est en soi le constat à remonter.
- Décidez à partir de l’état du runbook — reprendre ou abandonner — plutôt qu’en agissant sur l’environnement. Agir hors du runbook rend l’enregistrement faux pour la prochaine personne qui posera cette question.
En cas de problème
| Symptôme | Cause | Comment vérifier | Solution |
|---|---|---|---|
| L’onglet Pull Requests ou Jira manque | Cette intégration n’est pas activée | Settings › Development › Integrations | Connectez-la, ou acceptez son absence |
| L’étape Jira indique que le système n’a pas de projet | Aucun projet rattaché à ce système | Le message de l’assistant | Rattachez le projet, ou continuez sans |
| Impossible d’ouvrir une release | access sans release.view.details |
Access Explorer | Demandez la permission de détail |
| Actions rapides absentes | Il manque release.view.details.quick-actions |
Access Explorer | Demandez-la — elle est distincte de la consultation |
| Impossible de supprimer la release d’un autre | Exige release.admin-delete |
Access Explorer | Volontairement distincte ; demandez-la explicitement |
| La release dit déployé, l’environnement dit non | Quelqu’un a agi directement sur l’environnement | L’onglet Events de l’environnement | Réconciliez ici pour que l’enregistrement reste exact |
Pour aller plus loin
- Runbook MEP — l’exécution de la release
- Configuration — les règles qui encadrent tout cela