Déploiements

Ce que contient un déploiement

Un déploiement a un nom, une heure planifiée et une liste de versions d'enregistrements. L'heure est obligatoire, et tant que le déploiement est planifié, vous pouvez modifier son nom, sa description, son heure et ses éléments.

Il ne porte que des versions d'enregistrements. Les changements des modèles et de la configuration sont livrés dans une publication, et un déploiement peut désigner une publication planifiée à partir en premier. La publication est alors livrée à l'heure du déploiement, avant le contenu. Si elle est refusée ou échoue, le déploiement est marqué comme échoué avec le motif et aucun de ses contenus n'est publié.

Ce qui se passe quand un élément échoue

Tous les éléments s'exécutent dans une seule transaction de base de données, chacun sous son propre savepoint. Un élément qui échoue est annulé seul et enregistré comme échoué. Les autres sont quand même publiés, et ils deviennent visibles ensemble à la validation de la transaction. Ensuite, le déploiement indique Completed si tous les éléments ont réussi, Partial si certains ont échoué et Failed si tous ont échoué.

Les commandes

Un déploiement planifié peut être déclenché plus tôt, suspendu et repris, et il peut être supprimé tant qu'il n'a pas été déclenché. Retry relance uniquement les éléments qui ont échoué. L'annulation republie la version précédemment publiée de chaque élément. Vous pouvez prévisualiser une annulation avant de l'exécuter, et l'aperçu signale tout élément qui n'a pas de version publiée antérieure.

Où les gérer

Les déploiements se gèrent dans la console sous Content, Scheduled, Rollouts, depuis la CLI avec foir rollouts, et via des outils d'agent. L'API GraphQL publique ne les gère pas. Pour la CI, le modèle documenté est une tâche planifiée qui crée le déploiement à partir d'un fichier avec la CLI. Pour en créer un, la permission schedules:write est requise.