Concepts

Aperçus et publication

Pourquoi chaque modification est expédiée via une URL d'aperçu avant la production.

La chose la plus opiniâtre à propos de Showly : la production ne reçoit rien qui n'ait déjà été un aperçu. Cette page explique pourquoi et ce que cela signifie dans la pratique.

Qu'est-ce qu'un aperçu

Un aperçu est un artefact de construction immuable plus une URL routable. Il porte :

  • le commit SHA auquel le patch a été appliqué
  • la différence avec l'artefact de production en direct
  • le journal de build
  • vérifier les résultats (peluches, vérification de type, crochets CI personnalisés)
  • l'agent ou l'humain qui l'a produit

Les aperçus d'un espace de travail authentifié vivent dans un espace de noms isolé. Ils sont bloqués pour les robots (X-Robots-Tag: noindex), n'expirent jamais et ne partagent aucun secret avec la production. L'essai public sans compte et non revendiqué est un flux distinct : il expire toujours au bout d'environ une heure s'il n'est pas revendiqué.

Comment un aperçu est déclenché

Il existe trois manières de produire une build :

  • Votre agent (Claude Code / Codex sur MCP) appelle create_preview après avoir organisé un changement.
  • Vous construisez à partir de GitHub connecté. Web et MCP peuvent résoudre la branche connectée et créer un aperçu privé protégé par mot de passe ; Pro+ les espaces de travail peuvent choisir l'accès des membres de l'espace de travail à la place. Le déploiement automatique push est désactivé par défaut et, lorsqu'il est explicitement activé, crée uniquement un aperçu membre de l'espace de travail privé, jamais une version Live. Le déploiement automatique sans assistance nécessite actuellement Pro+ et une cible de build statique ; les cibles d'exécution non prises en charge sont ignorées avec une notification dans l'application. (La source est clonée avec un jeton d'application GitHub de courte durée et de portée qui n'entre jamais dans l'environnement de construction.)
  • Une nouvelle tentative/reconstruction. Un déploiement échoué ou annulé peut être reconstruit — à partir du bouton Reconstruire du tableau de bord ou de l'outil retry_deployment MCP. Showly conserve le bundle source, donc une reconstruction se fait en un clic sans nouveau téléchargement.

Chaque chemin atterrit sur le même artefact + URL d'aperçu. Les versions préliminaires sont gratuites. Un déploiement de production réussi consomme 15 crédits ; production ratée ce n’est pas le cas des déploiements. Si une build échoue, le déploiement passe par l'étape d'échec, un code d'erreur, un message et une queue du journal de construction afin que vous puissiez voir pourquoi avant de réessayer.

Pour l'accès par mot de passe, Showly génère un court code de partage XXX-XXX avec les caractères ambigus supprimés. Vous pouvez plutôt choisir n’importe quel mot de passe de 6 à 128 caractères. Le texte en clair s'affiche uniquement lorsque l'aperçu est créé ou que son mot de passe est pivoté ; utilisez Copier l'URL + le mot de passe pour copier un bloc d'informations d'identification prêt à être transféré. Les mots de passe existants restent valides jusqu'à ce que vous les alterniez. Pour les avis internes sensibles, préférez l'accès organisation Pro ou choisissez un mot de passe plus long.

Qu'est-ce qu'une publication

Une publication est la promotion d'un _artefact d'aperçu existant_ vers la route de production. Showly ne se reconstruit pas lors de la publication. L'artefact que vous avez approuvé est celui qui est expédié. C'est ce qui rend la restauration sûre : la restauration consiste à « remplacer le pointeur de route vers l'arrière », et non à « réexécuter la construction ».

Preview et Live sont des adresses distinctes. L'aperçu reste privé et ne se transforme jamais en URL publique ; la publication crée un déploiement de production pour l'adresse Live du site. L'aperçu source reste disponible jusqu'à sa suppression explicite, sans expiration liée au forfait.

Qu'est-ce que l'approbation

L'approbation est une décision enregistrée par un membre de l'espace de travail qui est autorisé à approuver la publication. Les rôles sont owner, admin, developer, deployer et viewer ; une demande de publication créée sur MCP nécessite une approbation d'un owner ou d'un admin. La décision est durable : même si l'approbateur quitte l'espace de travail demain, le dossier d'audit le désigne comme approbateur de la révision N. Un demandeur ne peut pas approuver sa propre demande et un rejet est définitif.

Les workflows d'approbation sont contrôlés par le droit approvalWorkflows. Quand il est désactivé, le demandeur publie avec une action explicite du navigateur ou le confirmation en deux étapes publish_site de l'agent. L'inscription à OTP/MFA n'est pas requis, et la porte d'approbation renoncée est enregistrée dans le journal d'audit.

Qu'est-ce qu'un retour en arrière

Le bouton Rollback de l'éditeur échange le pointeur d'itinéraire en direct vers un artefact antérieur. La restauration reste une action distincte à haut risque avec ses propres contrôles de confirmation. L'artefact annulé est _conservé_ — vous pouvez le re-promouvoir plus tard si l'annulation s'avère avoir été un mauvais appel.

Pourquoi la boucle de publication est importante

Une publication typique Showly va :

  1. L'agent appelle create_change_plan → un humain examine le plan.
  2. L'agent appelle apply_site_patch + create_preview → prévisualiser l'URL générée.
  3. Aperçu des visites humaines, parcourt les flux critiques.
  4. Facultatif : run_checks exécute la matrice de vérification personnalisée de l'espace de travail.
  5. L'agent appelle request_publish → une approbation en attente est créée. L'outil renvoie une enveloppe d'approbation (voir ci-dessous) avec un lien profond webApprovalUrl.
  6. Un membre de l'espace de travail ouvre le webApprovalUrl et approuve (ou refuse) la demande.
  7. Un humain clique sur Publier dans l'interface utilisateur Web ; aucune configuration OTP n’est requise. La publication promeut le déploiement d'aperçu approuvé vers la production et porte sourceDeploymentId défini sur l'identifiant de ce déploiement d'aperçu.

request_publish renvoie une enveloppe d'approbation :

{
  "approvalId": "apr_...",
  "deploymentId": "dep_...",
  "state": "pending",
  "expiresAt": "2026-05-31T10:00:00.000Z",
  "reused": false,
  "webApprovalUrl": "https://showly.ai/app/deployments/dep_.../publish"
}

state est l'un des pending, approved, denied ou expired, et reused est true lorsqu'une approbation en attente existante pour le même déploiement est renvoyée au lieu d'une nouvelle. publish_site est également disponible via MCP en tant que flux de confirmation humaine en deux étapes, lié au déploiement.

Chaque étape est vérifiable ; chaque étape présente un mode de défaillance évident qui n'atteint pas la production.

Qu'en est-il des correctifs ?

Les correctifs passent toujours par un aperçu privé en premier. Il n'y a pas de contournement d'urgence : la publication nécessite toujours un aperçu prêt, la confirmation de publication explicite et toute approbation requise par l’espace de travail, mais pas l’inscription à OTP.