Actions Day-2
Les actions Day 2, depuis la ressource
Chaque opération après le premier déploiement est une action du Blueprint. Vous la lancez depuis la page de la ressource, avec son formulaire, son backend et sa règle d’approbation.
Actions sur une ressource déployée
Ce que Day-2 veut dire ici
Le Day 1 la crée. Le Day 2, c’est tout ce qui suit.
Une action Day-2, c’est toute action d’un Blueprint autre que la création. Mettre à l’échelle, redémarrer, reconfigurer, mettre à jour, lancer un plan, détruire. L’auteur du Blueprint les déclare une fois, et chaque ressource de ce type les porte dès sa création.
Elle a un backend
Chaque action s’exécute nativement ou dans la CI que vous opérez déjà. C’est une vraie exécution, avec ses logs et son statut, pas un bouton qui ouvre un ticket ailleurs.
Elle a un formulaire, si besoin
La mise à l’échelle demande un nombre de réplicas. Le redémarrage ne demande rien du tout. Le formulaire appartient à l’action : il n’y a rien à synchroniser.
Elle a sa propre règle
L’approbation se déclare par action : la mise à l’échelle en production peut exiger un approbateur nommé, tandis que le staging s’exécute sans intervention. Un seul Blueprint, aucune branche à maintenir.
Cycloid pour votre équipe
Ce que les actions Day 2 changent pour votre équipe
Ne soyez plus le passage obligé
Le problème
Chaque mise à l’échelle, rotation ou correctif arrive sous forme de ticket, et la solution est un pipeline que trois personnes seulement savent lancer sans risque.
Avec Cycloid
Déclarez l’action une fois sur le Blueprint, avec son formulaire, son backend et sa règle d’approbation, et chaque ressource de ce type en hérite.
Le résultat
Les opérations courantes ne passent plus par vous.
Exploitez ce que vous avez déployé
Le problème
Vous pouviez déployer, mais pas exploiter : tout ce qui vient après le jour 0 impose de demander à quelqu’un et d’attendre.
Avec Cycloid
Les actions se trouvent sur la page de la ressource que vous avez déjà ouverte, préremplies avec votre dernière soumission, dans les limites des droits que vous détenez déjà.
Le résultat
Vous la mettez à l’échelle vous-même un vendredi à 16 h, dans les règles.
Savoir qui a lancé quoi, sans demander
Le problème
Les opérations courantes sont invisibles jusqu’à ce que l’une d’elles tourne mal, et là personne ne sait dire qui a lancé quoi, ni avec quelle validation.
Avec Cycloid
Chaque action est une exécution avec un acteur nommé, une trace d’approbation et des logs, qu’elle ait tourné seule ou parmi quarante-sept dans un lot.
Le résultat
La gouvernance est le chemin que les gens empruntent, pas un rapport assemblé après coup.
En bref
Quarante-sept bases, une seule action
3
façons de lancer un lot
1
formulaire pour tout le lot
4
couches, vérifiées par ressource
0
ressources touchées hors de votre sélection
Passez l’API de production à six réplicas.
La production impose une approbation sur cette action : j’ai donc ouvert la demande au lieu de l’exécuter. Quoi qu’il arrive, elle attend la validation d’une personne.
En attente · scale prod-api
En attente d’approbation
Demandé par
Vous, via l’assistant
État
Rien n’a encore changé
Travailler avec votre assistant
Votre assistant ne peut pas lancer une action que vous ne pouvez pas lancer
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 mettre à l’échelle le cluster de staging : il appelle l’action que déclare le Blueprint, en votre nom, à travers les quatre mêmes couches de contrôle que le bouton. Vous voyez ce qui va changer, et rien ne s’exécute tant que vous n’avez pas donné votre accord.
Si la production exige une approbation, l’assistant ouvre la demande et attend une personne, exactement comme le formulaire. Il ne peut pas exécuter une action que le Blueprint n’a pas déclarée : ce qu’il peut faire, c’est ce que vous avez déjà publié.
Comment ça fonctionne
Cinq étapes, et aucune ne s’appelle « nouveau pipeline »
01 · Ouvrir la ressource
Configuration, statut en direct, relations et actions déclarées par ce Blueprint, le tout sur une seule page.
02 · Choisir l’action
Le formulaire s’ouvre prérempli avec votre dernière soumission. Les champs immuables sont verrouillés et les champs sensibles restent masqués.
03 · Confirmer le contexte
Environnement, fournisseurs et identifiants sont déjà liés : une action Day-2 n’a rien à vous faire résoudre.
04 · La suivre en direct
Une seule vue de statut et un seul flux de logs, qu’elle ait tourné sur le Native Runner ou dans votre propre CI.
05 · Ou la lancer sur quarante-sept
Quand une CVE touche quarante-sept bases de données, sélectionnez-les toutes et lancez une seule action. Chacune est autorisée séparément, en parallèle, par vagues ou une par une.
Chaque action Day-2 passe par les quatre mêmes couches que la création. Les relations, puis le rôle, puis les conditions, puis l’approbation. Agir sur ce qui existe déjà n’en assouplit aucune, et il n’y a pas de politique Day-2 distincte à aligner sur la première.
Cinq étapes, et aucune ne s’appelle « nouveau pipeline »
«
En tant que développeurs, nous avons adoré pouvoir opérer l’application de manière simple.
Guillaume Maubert
PDG, Alchemy
Questions fréquentes
Tout ce que le Blueprint déclare au-delà de la création. Mise à l’échelle, redémarrage, mise à jour, lancement d’un plan, destruction, ou toute opération propre à votre stack. Chacune est une vraie exécution, avec ses propres logs et son statut.
Oui. L’approbation se déclare par action et peut dépendre de l’environnement : la mise à l’échelle en production exige un approbateur nommé, le staging s’exécute sans intervention. Une seule définition d’action, pas deux Blueprints.
Il va vers l’avant. Pas d’annulation, pas d’état sauvegardé à restaurer. Vous choisissez un build antérieur dans l’historique de la ressource, et il s’exécute comme une mise à jour ordinaire, avec le même formulaire et les mêmes approbations.
Non. Vous cliquez sur l’action, depuis la ressource. L’orchestration la suit, diffuse les logs et confie le travail au backend déclaré, natif ou votre propre CI. Le pipeline devient une tuyauterie que vous n’ouvrez jamais.
Apportez l’opération que vous faites encore à la main
Choisissez celle qui exige un runbook, quelqu’un qui connaît l’astuce et un message Slack à son responsable. En vingt minutes, nous en faisons une action sur la ressource, avec son formulaire et sa règle d’approbation.