Communitygithub.com

RosieAlan/agent

Guide de déploiement et d'hébergement pour Prisma Compute.

Qu'est-ce que agent ?

Ce guide fournit des instructions complètes pour créer, déployer et gérer des applications Prisma Compute, en passant par la configuration typée avec `prisma.compute.ts`, les commandes CLI (`@prisma/cli app deploy`, `create-prisma`), l'authentification avec jetons de service ou OAuth, et la gestion des espaces de travail, branches, environnements et bases de données. Il couvre également la préparation des frameworks supportés (Next.js, Hono, Astro, Nuxt, Nest, Turborepo, etc.) pour le déploiement, notamment la liaison sur `0.0.0.0` et le port HTTP. L'utilisateur y trouvera des arbres de décision pour diagnostiquer les échecs, des règles de priorité pour l'exécution des commandes, et un workflow recommandé pour inspecter le projet, vérifier l'auth, et choisir entre déploiement d'app existante ou nouveau projet. Conçu pour les agents IA et les développeurs, ce guide s'applique aux workflows interactifs et non interactifs (CI/CD), et s'appuie sur les sources officielles (sorties `--help`, code généré, documentation).

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/RosieAlan/agent/tree/HEAD/chapter-02-%E5%B7%A5%E7%A8%8B%E5%BA%95%E5%BA%A7/llm/services/chat/.agents/skills/prisma-compute

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Prisma Compute

Guide les agents à travers la création, le déploiement, les opérations et la préparation au déploiement spécifique aux frameworks pour les applications Prisma Compute.

Surface CLI de Prisma Compute

Utilisez la CLI de la plateforme Prisma pour les workflows des applications Compute :

bunx @prisma/cli@latest app deploy --help
bunx @prisma/cli@latest app --help
bunx @prisma/cli@latest build logs --help
bunx create-prisma@latest --help

Utilisez @prisma/cli@latest pour le déploiement des applications Compute. Utilisez create-prisma@latest pour l'échafaudage de nouveaux projets.

Envoyer des commentaires et signaler des problèmes CLI

La CLI dispose d'un canal de commentaires intégré. Utilisez-le à chaque fois qu'une commande plante (UNEXPECTED_ERROR), qu'un échec persiste après le dépannage, ou que l'utilisateur demande à envoyer des commentaires à l'équipe Prisma :

bunx @prisma/cli@latest feedback "app deploy crashed: <première ligne d'erreur>"
bunx @prisma/cli@latest feedback "j'adore le flux de déploiement" --email [email protected]

La sortie de plantage pointe vers ceci automatiquement : les enveloppes de plantage --json contiennent la commande exacte pré-remplie comme entrée recover dans nextActions (exécutez-la textuellement), et la sortie de plantage humaine se termine par une invite Dites-nous ce qui s'est passé :. Les commentaires sont anonymes sauf si --email est passé et n'attache que la version de la CLI, la version de Node et le système d'exploitation/architecture. N'incluez jamais de secrets, d'URL de connexion ou de données utilisateur dans le message.

Ordre des sources de vérité

Utilisez les preuves dans cet ordre lorsque vous décidez quoi éditer ou exécuter :

  1. Les scripts et configurations générés du projet, en particulier prisma.compute.ts, compute:deploy, la configuration du framework et package.json.
  2. La sortie d'aide de la CLI de create-prisma et @prisma/cli.
  3. Le code du paquet installé localement, les artefacts générés et les définitions de types.
  4. La documentation officielle.

Quand appliquer

Utilisez cette compétence pour :

  • Créer une nouvelle application pouvant être déployée sur Prisma Compute
  • Déployer une application TypeScript existante sur Prisma Compute
  • Créer ou mettre à jour une configuration de déploiement typée prisma.compute.ts
  • Décider si un framework est prêt pour Compute
  • Déboguer create-prisma --deploy, compute:deploy ou app deploy
  • Gérer les logs, les déploiements, les variables d'environnement et les domaines des applications Compute, et lister les branches de la plateforme (branch list ; il n'y a pas de commandes de création/suppression de branche)
  • Inspecter les logs de build GitHub/Console et le statut de déploiement par push GitHub
  • Exécuter des déploiements non interactifs avec authentification par navigateur, plusieurs espaces de travail stockés ou jetons de service Prisma
  • Basculer, sélectionner, lister ou se déconnecter des espaces de travail locaux de la plateforme Prisma pour @prisma/cli
  • Envoyer des commentaires sur un échec insoluble de la CLI Compute avec @prisma/cli feedback
  • Déploiements programmatiques avec @prisma/compute-sdk ou les intégrations de l'API de gestion

Arbre de décision

  1. Déploiement ou redéploiement d'un projet existant : Lisez references/app-deploy-cli.md.

  2. Configuration Compute typée, monorepos, cibles de déploiement, racines d'application ou valeurs par défaut de build/env : Lisez references/compute-config.md.

  3. Travail spécifique au framework (build/runtime) : Lisez references/frameworks.md.

  4. Nouveau projet à partir d'un échafaudage : Lisez references/create-prisma.md.

  5. Déploiement programmatique, SDK, API ou concepts avancés d'application/déploiement : Lisez references/sdk-api.md.

  6. Échecs de build, d'auth, d'env, de déploiement ou d'exécution : Lisez references/troubleshooting.md.

Règles par priorité

PrioritéCatégorieImpactPréfixe
1Vérification de commandeCRITIQUEverify-
2Authentification et sélection d'espace de travailCRITIQUEauth-
3Préparation du frameworkCRITIQUEframework-
4Liaison de l'hôte et du port d'exécutionCRITIQUEruntime-
5Configuration Compute typéeÉLEVÉEconfig-
6Branche, environnement et base de donnéesÉLEVÉEenv-
7Opérations de déploiementÉLEVÉEdeploy-
8Automatisation SDK et APIMOYENNEsdk-

Règles rapides

1. Vérification de commande

  • verify-help-first - Utilisez la sortie d'aide de la CLI pour confirmer la syntaxe des commandes pendant le travail.
  • verify-prisma-vs-platform-cli - Ne supposez pas que prisma app deploy existe dans la CLI ORM ; vérifiez si la tâche doit utiliser @prisma/cli.
  • verify-generated-scripts - Préférez le script généré compute:deploy lorsqu'un projet en possède déjà un.
  • verify-public-url - Après un véritable déploiement, demandez l'URL de déploiement publique au lieu de vous fier aux vérifications locales ou de simple disponibilité.
  • verify-config-support - Traitez prisma.compute.ts comme la configuration Compute typée ; inspectez la configuration du projet et les scripts générés avant de modifier ou déployer.
  • verify-auth-workspace-support - Utilisez les commandes @prisma/cli auth workspace pour les flux de liste/utilisation/déconnexion de l'espace de travail local.

2. Authentification et sélection d'espace de travail

  • auth-source-precedence - Un PRISMA_SERVICE_TOKEN non vide est la source d'authentification active pour les commandes et les espaces de travail OAuth locaux sont ignorés pour l'exécution. S'il est défini mais vide, la CLI doit échouer au lieu de revenir à l'OAuth stocké.
  • auth-multi-workspace - auth login peut stocker des sessions OAuth pour plusieurs espaces de travail sur la même machine. Le pointeur d'espace de travail actif sélectionne la subvention OAuth stockée que les commandes normales utilisent.
  • auth-list-before-switch - Utilisez auth workspace list --json pour inspecter les sessions locales. Les agents doivent préférer les ID d'espace de travail du JSON aux noms, car les noms peuvent être ambigus.
  • auth-switch-explicitly - Utilisez auth workspace use <id-ou-nom> pour un changement non interactif. Utilisez auth workspace use sans argument uniquement pour un sélecteur interactif ou lorsqu'il existe exactement un espace de travail OAuth local.
  • auth-no-fallthrough - Si l'espace de travail OAuth actif est déconnecté ou échoue à se rafraîchir, la CLI ne doit pas passer silencieusement à un autre espace de travail mis en cache. Exécutez auth workspace use <id> pour choisir l'espace de travail suivant.
  • auth-single-workspace-logout - Utilisez auth workspace logout <id-ou-nom> ou auth logout --workspace <id-ou-nom> pour supprimer une session d'espace de travail OAuth locale. auth logout simple efface toutes les sessions d'espace de travail OAuth locales.
  • auth-service-token-switching - Pendant que PRISMA_SERVICE_TOKEN est défini, auth workspace use est indisponible car le jeton de service est la source d'authentification active ; désactivez la variable d'env pour changer d'espace de travail OAuth local. La déconnexion de l'espace de travail ne nettoie toujours que l'état OAuth local.
  • auth-storage-awareness - Les identifiants OAuth locaux résident dans le fichier d'authentification de la plateforme, avec les métadonnées de l'espace de travail dans un fichier de contexte sidecar. Les épingles de projet vivent dans .prisma/local.json, et l'état de l'application CLI/projet vit dans .prisma/cli/state.json près de prisma.compute.ts lorsqu'il est présent.

3. Préparation du framework

  • framework-cli-first - Évaluez la préparation au déploiement par rapport à @prisma/cli app deploy, pas par rapport à ce que create-prisma peut échafauder.
  • framework-supported-cli-deploy - Le déploiement Compute prend en charge nextjs, nuxt, astro, hono, nestjs, tanstack-start, custom et bun.
  • framework-create-prisma-defaults-only - create-prisma peut fournir des valeurs par défaut générées et compute:deploy, mais ce n'est pas la surface de déploiement générale pour les applications existantes.
  • framework-build-output - Compute a besoin d'un point d'entrée serveur ou d'un artefact de framework, pas seulement d'une sortie statique.

4. Liaison de l'hôte et du port d'exécution

  • runtime-bind-all-interfaces - Les serveurs déployés doivent se lier sur toutes les interfaces (0.0.0.0 ou l'équivalent du framework), pas de localhost ou 127.0.0.1 codé en dur.
  • runtime-match-http-port - L'application doit écouter sur le port HTTP déployé : lisez process.env.PORT lorsque c'est possible, ou passez le --http-port correspondant.
  • runtime-readiness-port-only - La vérification de disponibilité Compute surveille les ports d'écoute ; un écouteur en boucle locale peut sembler prêt alors que l'entrée publique ne peut pas l'atteindre.
  • runtime-respond-within-60s - L'entrée donne à une application 60 secondes pour commencer à répondre, puis renvoie 504 Gateway Time-out et annule la requête. Concevez les gestionnaires pour répondre d'abord et exécutez les travaux plus longs sous waitUntil ou à partir d'une file d'attente, jamais à l'intérieur de la requête.

5. Configuration Compute typée

  • config-optional-simple-app - prisma.compute.ts n'est pas requis pour déployer une application simple normale ; utilisez des flags lorsqu'il n'y a pas de configuration durable.
  • config-init-formalizer - Générez une nouvelle configuration avec bunx @prisma/cli@latest init : il détecte le framework, épingle le nom/le framework/le httpPort (plus le point d'entrée pour Bun/Hono) et propose le lien du projet. --format json écrit un prisma.compute.json sans dépendances à la place. init refuse lorsque toute configuration existe déjà, n'échafaude jamais de code et ne déploie jamais.
  • config-use-prisma-compute-ts - Mettez les valeurs par défaut de déploiement réutilisables dans prisma.compute.ts avec defineComputeConfig, pas dans prisma.config.ts.
  • config-app-vs-apps - Utilisez app pour une seule cible de déploiement et apps pour les monorepos ou les repos multi-applications ; définissez exactement une.
  • config-monorepo-roots - Pour les monorepos, utilisez prisma.compute.ts pour déclarer les cibles de l'application, les racines, les valeurs par défaut du framework, les points d'entrée, les ports et les entrées d'env.
  • config-targets - Dans les configurations multi-applications, @prisma/cli app deploy web sélectionne la cible apps.web. Sans [app], les commandes peuvent déduire la cible du répertoire actuel ; autrement, le déploiement peut exécuter toutes les cibles tandis que le build/run en nécessite une.
  • config-region-new-app-only - Une region de configuration n'est qu'une valeur par défaut pour les applications nouvellement créées ; les déploiements vers des applications existantes conservent la région actuelle de l'application.
  • config-custom-artifact - Utilisez framework: "custom" avec build.outputDirectory et build.entrypoint pour les artefacts pré-construits ou construits sur mesure.
  • config-no-project-branch-secrets - Ne commitez pas l'espace de travail, le projet, la branche, l'intention de production, les jetons de service ou les valeurs secrètes dans prisma.compute.ts ; conservez-les dans les flags, .prisma/local.json, le stockage d'env ou les secrets CI. Les valeurs par défaut au niveau de l'application telles que region, root, framework, entry, httpPort et les chemins de fichiers d'env non secrets appartiennent à la configuration.
  • config-flags-win - Les flags de déploiement explicites tels que --framework, --entry, --http-port, --region et --env remplacent les valeurs de configuration correspondantes.

6. Branche, environnement et base de données

  • env-do-not-leak-secrets - N'imprimez jamais intégralement DATABASE_URL, les jetons de service ou les valeurs secrètes.
  • env-deploy-loads-dotenv - Les scripts de déploiement générés peuvent charger l'env via prisma.compute.ts ou --env .env ; inspectez le script/la configuration réelle avant de redéployer.
  • env-migrations-separate - Les scripts de redéploiement n'exécutent pas les migrations ou les données d'amorçage. Exécutez les scripts de base de données Prisma appropriés séparément.
  • env-cli-token-name - @prisma/cli utilise PRISMA_SERVICE_TOKEN pour l'authentification par jeton de service.
  • env-branch-scope - Les déploiements de branche, les variables d'env de branche et les bases de données de branche doivent utiliser le même nom de branche ; passez --branch <nom-git> explicitement lors du ciblage d'une branche de prévisualisation.
  • env-production-vs-preview - Utilisez --role production pour l'env de production, --role preview pour l'env modèle de prévisualisation, et --branch <nom-git> pour les remplacements spécifiques à la branche.
  • env-db-explicit - Gardez le câblage de la base de données et de l'env explicite via les commandes de base de données et d'env du projet ; les exemples de déploiement ne doivent pas ajouter de configuration de base de données, et les déploiements n'exécutent pas de migrations, de données d'amorçage ou ne créent pas une base de données par application automatiquement.

7. Opérations de déploiement

  • deploy-prod-intent - Utilisez --prod --yes uniquement lorsque l'utilisateur a l'intention d'un déploiement de production. Le premier déploiement de production d'une application se promeut automatiquement sans --prod ; le flag restreint les déploiements ultérieurs de la branche de production.
  • deploy-no-promote - Utilisez app deploy --no-promote pour build-vérifier : il construit un candidat accessible à sa propre URL sans toucher au déploiement en direct, promu plus tard avec app promote <id-déploiement>.
  • deploy-github-default-branch - Lorsqu'une application Compute est connectée à GitHub push-to-deploy, une fusion vers la branche par défaut est le chemin de déploiement de production ; vérifiez les enregistrements de déploiement ou les vérifications GitHub au lieu de dire aux utilisateurs de redéployer la branche PR fusionnée ou d'exécuter un déploiement de prévisualisation de la branche par défaut.
  • deploy-build-logs - Utilisez @prisma/cli build logs <id-build> pour la sortie de build GitHub/Console. Utilisez app logs pour les logs d'exécution du déploiement ; les deux identifiants sont différents.
  • deploy-noninteractive-auth - Les déploiements non interactifs nécessitent soit l'espace de travail OAuth stocké actif correct, soit une variable d'env de jeton de service prise en charge ; n'imprimez jamais le jeton.
  • deploy-json-for-agents - Utilisez --json --no-interactive pour les scripts et la sortie lisible par machine.
  • deploy-create-project - Utilisez --create-project <nom> uniquement lorsque l'utilisateur souhaite que le déploiement crée et lie un nouveau projet ; il entre en conflit avec --project et PRISMA_PROJECT_ID.
  • deploy-ops-targets - Les commandes app show/open/logs/list-deploys/promote/rollback/remove et domain peuvent également accepter les cibles [app] de prisma.compute.ts.
  • deploy-report-cli-bugs - En cas d'UNEXPECTED_ERROR ou d'un échec insoluble, signalez-le avec la commande de commentaires ; voir la section "Envoyer des commentaires et signaler des problèmes CLI" ci-dessus.

8. SDK et API

  • sdk-use-cli-first - Préférez @prisma/cli app deploy pour les workflows d'application ; utilisez create-prisma uniquement pour échafauder une nouvelle application, sauf si l'utilisateur construit une automatisation de plus bas niveau.
  • sdk-result-handling - @prisma/compute-sdk renvoie des valeurs Result ; vérifiez isOk()/isErr() au lieu de compter sur les exceptions.
  • sdk-snapshot-detection - Utilisez detectComputeApp pour les instantanés de dépôt qui ne sont pas extraits sur le disque ; énumérez vous-même les espaces de travail et appelez-la une fois par racine d'application candidate.

Workflow préféré

  1. Inspectez le projet : gestionnaire de paquets, modèle/framework, scripts package.json, version de Prisma, emplacement du client Prisma, prisma.compute.ts et compute:deploy existant.
  2. Vérifiez la sortie d'aide de la CLI pour le paquet réellement utilisé.
  3. Vérifiez le contexte d'authentification avant les mutations de projet/application : auth whoami --json, et lorsque plusieurs sessions locales peuvent exister, auth workspace list --json.
  4. Choisissez le chemin :
    • déploiement d'application existante : cible basée sur la configuration lorsqu'elle est présente, compute:deploy généré, ou flags @prisma/cli app build/run/deploy
    • nouvel échafaudage d'application : create-prisma, puis compute:deploy généré ou @prisma/cli app deploy
    • bas niveau...

… [tronqué pour la traduction]

Skills associés