Chemin de promotion
Promouvez vous-même. Chaque règle tient.
Les développeurs font passer leur travail de dev à staging puis en production sans solliciter l’équipe plateforme. Les contrôles définis par cette équipe s’appliquent à chaque étape.
Promouvoir vers staging
Le vrai coût
Chaque promotion reste un ticket
Faire passer un build testé dans l’environnement suivant revient généralement à solliciter l’équipe plateforme, qui le vérifie, le redéploie et ferme le ticket. Multipliez cela par chaque service et chaque étape, et votre équipe plateforme passe sa semaine à tenir un guichet de mise en production.
Les développeurs attendent à chaque étape
Un build validé en recette le mardi arrive en staging quand quelqu’un a le temps, pas quand il est prêt.
L’équipe plateforme se répète
Les mêmes vérifications, faites à la main, pour chaque promotion de chaque service.
La production s’écarte du staging
Chaque redéploiement manuel est une occasion de saisir une autre valeur que celle validée en staging.
Une plateforme, trois points de vue
Ce qu’un chemin de promotion change pour votre équipe
Définir les règles une fois
Le problème
Vous êtes le point de passage obligé entre chaque environnement.
Avec Cycloid
Des politiques de promotion au niveau du tenant, de l’équipe ou du Blueprint, vérifiées sur la source avant que quoi que ce soit n’atteigne l’étape suivante.
Le résultat
Vous tracez le chemin. Vous ne le faites plus parcourir à chacun.
Faire avancer son propre build
Le problème
Un build testé attend que quelqu’un d’autre le fasse avancer.
Avec Cycloid
Cliquez sur « Promouvoir vers staging ». Si un contrôle échoue, il vous dit lequel.
Le résultat
Votre rythme, dans les règles.
La production reçoit ce que le staging a validé
Le problème
Au moment de la mise en production, vitesse et contrôle tirent en sens inverse.
Avec Cycloid
La version validée à une étape est celle qui atteint la suivante, et chaque contournement est journalisé.
Le résultat
Des livraisons plus rapides, auditables.
Comment ça fonctionne
Du dev à la production, une porte à la fois
01 · Cliquez sur Promouvoir
« Promouvoir vers staging » est un bouton de la ressource déployée. La plateforme vérifie les contrôles avant d’ouvrir quoi que ce soit.
02 · Les portes vérifient d’abord la source
Durée de stabilisation, étapes précédentes requises, approbation, niveau de scorecard tel que Silver, version de Blueprint. Un contrôle en échec est désigné par son nom.
03 · Le formulaire s’ouvre prérempli
La première arrivée crée une nouvelle ressource dans l’environnement cible. Ensuite, la promotion met à jour la ressource existante sur place, sans toucher aux champs d’environnement.
04 · Des règles qui ne font que s’ajouter
Le tenant fixe le socle. Équipes et Blueprints peuvent ajouter des contrôles, jamais en retirer.
05 · Composez, promouvez d’un bloc
Une composition construite à partir d’emplacements du catalogue est promue d’un bloc, et chaque élément enfant passe chaque contrôle.
La promotion est optionnelle et s’active au niveau du tenant ou de l’équipe. De dev à staging, la promotion peut se déclencher d’elle-même dès que les contrôles passent. Un hotfix ne peut contourner les contrôles que pour les personnes disposant du droit de contournement, et le contournement est journalisé. Il ne s’applique jamais à un premier déploiement, qui commence toujours à la première étape.
Les contrôles par scorecard sont inclus dans les offres Advanced et Enterprise.
Du dev à la production, une porte à la fois
En bref
Les règles que suit une promotion
3
niveaux où définir une règle de promotion
0
façons pour une règle locale d’assouplir une règle globale
1
unité de promotion pour une composition
1st
étape d’entrée de tout nouveau déploiement, contournement ou non
Promouvez checkout-api vers staging.
Un contrôle a échoué. Il passera dès que la scorecard atteindra Silver.
Promotion · checkout-api, de dev vers staging
1 contrôle en échec
Stabilisation
Réussi
Approbation
Non requise
Scorecard Silver ou plus
Bronze aujourd’hui
Travailler avec votre assistant
Demandez ce qui bloque le staging, obtenez le contrôle en échec
L’assistant a-t-il ses propres droits ?
Non. Il n’y a ni compte de service ni rôle d’assistant aux droits étendus. Si vous ne pouvez pas déployer en production, l’assistant avec lequel vous échangez ne le peut pas non plus, que ce soit dans l’assistant de Cycloid ou dans n’importe quel hôte MCP compatible.
Demandez à votre assistant de promouvoir checkout vers staging : il lance la même promotion que le bouton. Mêmes contrôles, même parcours pas à pas, en votre nom.
Si le contrôle de scorecard échoue, c’est la réponse que vous obtenez, avec son nom. Votre assistant ne peut pas contourner un contrôle que vous ne pourriez pas contourner vous-même.
Questions fréquentes
Non. La première promotion vers un environnement y crée une nouvelle ressource à partir de la même version épinglée du Blueprint. Les promotions suivantes mettent à jour cette cible sur place, sans toucher à ses paramètres d’environnement.
Uniquement pour les personnes qui disposent du droit de contournement de promotion. Le contournement est consigné dans le journal d’audit, et il ne s’applique jamais à un premier déploiement, qui entre toujours dans la chaîne par sa première étape.
La chaîne suit les types d’environnement dont vous disposez. Deux étapes donnent un chemin plus court, et si vous ajoutez un staging plus tard, il suffit de mettre la politique à jour pour l’inclure. Rien d’autre dans la chaîne n’a à changer.
Oui, à partir d’une composition. La personne qui déploie remplit les emplacements que l’auteur a autorisés, chaque élément enfant exige son propre droit d’utilisation, et la composition entière est ensuite promue dans la chaîne comme une seule unité.
Apportez la mise en production qui exige toujours un ticket
Vingt minutes, et le chemin de dev à la production que votre équipe parcourt aujourd’hui à la main. Nous le configurons en politique de promotion et vous montrons un contrôle refuser un build qui n’est pas prêt.