Configuration des déploiements
À quoi sert cet écran
Configuration définit les règles que suit chaque release : quels environnements une release peut viser, qui doit la valider, comment les notifications sont envoyées, et à quoi ressemblent les notes de release.
Mettez cela en place avant votre première release. Ces réglages façonnent les releases créées ensuite, et greffer des règles d’approbation sur un processus dont les gens ont déjà pris les habitudes est bien plus difficile que de commencer avec.
Avant de commencer
Chaque onglet a sa propre permission, ce qui permet de répartir les responsabilités :
| Onglet | Permission |
|---|---|
| General Settings | deployment-manager.config.general |
| Environments | deployment-manager.config.environments |
| Release Sign-offs | deployment-manager.config.signoff-roles |
| Notifications | deployment-manager.config.notifications |
| Release Notes Template | deployment-manager.config.release-notes-template |
Deux permissions supplémentaires couvrent des zones configurées à côté de
celles-ci : deployment-manager.config.jira et
deployment-manager.config.tag-patterns.
Un onglet dont vous n’avez pas la permission est en lecture seule ou absent. C’est voulu : quelqu’un peut être responsable des notifications sans pouvoir affaiblir les règles de validation.
Ouvrir l’écran
- Deploy › Deployments, puis Configuration.
URL directe : /deployment-manager/configuration
L’interface
📸 Capture d’écran : La page Configuration sur l’onglet Environments. Repères : (1) les cinq onglets, (2) le champ Allowed Clusters, (3) l’enregistrement.
| Onglet | Ce qu’il configure |
|---|---|
| General Settings | Le comportement général du Release Manager |
| Environments | Les environnements qu’une release peut viser, et les Allowed Clusters de chacun |
| Release Sign-offs | Les rôles qui doivent approuver avant qu’une release ne progresse |
| Notifications | Destinataires e-mail : qui est prévenu, et quand |
| Release Notes Template | La forme que prennent les notes de chaque release |
Procédures
Déclarer les environnements que les releases peuvent viser
Nécessite deployment-manager.config.environments.
- Configuration › Environments.
- Ajoutez l’environnement et renseignez ses Allowed Clusters.
- Enregistrez.
Allowed Clusters est le garde-fou : il empêche une release destinée à un environnement d’atterrir sur un cluster qui n’était pas censé la recevoir.
Définir les rôles de validation
Nécessite deployment-manager.config.signoff-roles.
- Configuration › Release Sign-offs.
- Choisissez les rôles qui doivent approuver.
- Enregistrez.
Les rôles proviennent de Personnes et accès › Rôles. Nommez un rôle, jamais une personne : les gens changent d’équipe et la règle ne doit pas les suivre.
Définir le modèle de notes de release
Nécessite deployment-manager.config.release-notes-template.
Définissez-le une fois et chaque release se décrira de la même façon. La valeur tient à la cohérence, pas à la formulation.
Scénario
Une release a atteint le mauvais cluster.
Personne n’a manifestement mal agi, ce qui désigne la configuration plutôt que l’opérateur.
- Configuration › Environments — trouvez l’environnement visé par la release.
- Lisez ses Allowed Clusters. Si le cluster qui a reçu la release y figure, la release a fait exactement ce pour quoi elle était configurée, et c’est la configuration qu’il faut corriger.
- Restreignez Allowed Clusters aux seuls clusters que cet environnement doit pouvoir atteindre. Enregistrez.
- Configuration › Release Sign-offs — si un humain aurait pu intercepter cela, ajoutez le rôle qui aurait dû le voir.
- Revérifiez Settings › Infrastructure › Environments. Deux environnements du même type sur des clusters différents est la façon habituelle dont cela arrive, et le correctif peut relever de là plutôt que d’ici.
L’intérêt de l’étape 2 : une release qui atterrit là où on ne l’attendait pas est presque toujours une cible autorisée que personne n’avait voulue, pas un bug.
En cas de problème
| Symptôme | Cause | Comment vérifier | Solution |
|---|---|---|---|
| Un onglet est en lecture seule | Les permissions de configuration sont par onglet | Access Explorer | Demandez la permission config.<zone> de cet onglet |
| Une release peut viser un cluster inattendu | Allowed Clusters est trop large | Configuration › Environments | Restreignez-le |
| Les validations ne sont pas demandées | Aucun rôle de validation configuré | Configuration › Release Sign-offs | Ajoutez les rôles |
| Un rôle manque dans le sélecteur de validation | Il n’existe pas | Rôles | Créez-le, puis revenez ici |
| Les notes de release sont incohérentes | Aucun modèle défini | Configuration › Release Notes Template | Définissez-en un |
| Aucun environnement proposé à la création d’une release | Aucun déclaré ici | Configuration › Environments | Déclarez-les |
Pour aller plus loin
- Releases — en créer une sous ces règles
- Settings › Infrastructure › Environments — d’où viennent les environnements
Slack se configure ailleurs
Cet onglet ne couvre que l’e-mail. Les notifications Slack se configurent pour toute la plateforme dans Settings › Development › Integrations, car un même espace de travail Slack est partagé par tous les plugins plutôt que détenu par le Release Manager.