Avant de commencer
Définir d'abord la limite d'exécution.
- Une application fonctionnelle avec des tests locaux répétables et un gestionnaire de paquets verrouillé.
- Un compte Cloudflare, une authentification Wrangler et un propriétaire de production nommé.
- Une liste des liaisons, secrets, régions de données et chemins de requête attendus.
- Un itinéraire de test à faible risque et une règle de décision de retour en arrière.
Étape par étape
Passer d'une portée à un artefact vérifié.
Choisissez le chemin de déploiement de manière délibérée
Pour une nouvelle application Next.js, commencez par vérifier la compatibilité avec vinext, car Cloudflare la recommande comme voie recommandée. Pour une déployment existante d'OpenNext, conservez l'adaptateur lorsque le gouffre de compatibilité n'est pas résolu. Utilisez Pages uniquement pour une véritable exportation statique.
- Point de vérification
- Le dépôt enregistre pourquoi vinext, OpenNext ou Pages statiques conviennent à cette application aujourd'hui.
- Artifact
- Enregistrement de décision du chemin de déploiement
Définir les limites de l'exécution et des données
Listez lesquelles des routes nécessitent un rendu serveur ou des API et lesquelles peuvent rester statiques. Ajoutez uniquement des D1, R2, KV, Workers AI, Files d'attente ou d'autres liaisons lorsqu'une fonction validée les exige. Documentez quelles données traversent chaque frontière et quel système est responsable de la suppression et de la récupération.
- Point de vérification
- Chaque liaison a une fonction nommée, un propriétaire de données et un comportement d'échec.
- Artifact
- Temps d'exécution et carte des liaisons
Rendre la construction reproductible
Fixez l'adaptateur et les outils de déploiement, générez des types liés, et exécutez des vérifications de types, des tests, une validation du contenu et la commande de construction exacte de la production. Gardez les secrets hors du contrôle de source et distinguez la configuration de prévisualisation de la configuration de production.
- Point de vérification
- Un checkout propre peut produire le même artefact de déploiement sans état local non documenté.
- Artifact
- Inventaire de configuration et de build vérifiés
Aperçu de l'artefact de production
Exécutez le Worker construit localement ou dans un environnement de prévisualisation, puis vérifiez les codes d'état, les redirections, les métadonnées, les actifs statiques, les limites authentifiées et toute migration de base de données. Traitez les liaisons d'IA distantes comme potentiellement facturables même pendant le développement local.
- Point de vérification
- L'artefact de production exact suit un itinéraire écrit et une matrice d'engagement.
- Artifact
- Enregistrement de test de fumée d'aperçu
Libérer une version traçable
Générer un marqueur de version publique à partir du commit, exécuter un test de déploiement, puis déployer la construction immuable. Enregistrer le commit, la version du Worker, le moment du déploiement et l'opérateur. Éviter de modifier les schémas de données et le comportement de l'application en une seule étape non revue.
- Point de vérification
- Le marqueur de version publique correspond au commit souhaité et le fournisseur de déploiement signale une version réussie.
- Artifact
- Enregistrement de la version de production
Vérifiez et maintenez la possibilité de restauration
Répéter la matrice de route contre le domaine public, y compris les vérifications critiques 200, redirection, 404, métadonnées et API. Surveiller les erreurs et les régressions visibles par l'utilisateur. Revenir en arrière lorsque la version casse un chemin critique ou viole la limite d'acceptation écrite à l'avance.
- Point de vérification
- La production correspond à l'enregistrement de la version de sortie, ou la version précédente fonctionnelle est restaurée.
- Artifact
- Décision de vérification publique et d'annulation
Livraisons
Gardez le travail réutilisable et inspectable.
- Enregistrement de décision du chemin de déploiement
- Temps d'exécution, données et carte des liaisons
- Commande de construction de production répétable
- Aperçu de la route et de la matrice de liaison
- Enregistrement de libération vers Worker
- Enregistrement de test de fumée publique et d'annulation
Limites des décisions
Ce que ce tutoriel ne prouve pas.
- Cloudflare étiquette vinext bêta ; vérifiez son rapport de compatibilité avant de migrer une application de production existante.
- OpenNext reste un chemin de maintenance documenté, mais il ne doit pas être présenté comme la norme de Cloudflare pour une nouvelle application.
- D1, R2, Workers AI et d'autres services ont des limites, des tarifs et un comportement des données séparés qui doivent être vérifiés pour le plan choisi.
- Un déploiement réussi ne prouve pas la correction de l'application, la sécurité, la récupération des données ou la qualité des sorties du modèle.
Registre des sources
Vérifier la guidance actuelle.
- Cloudflare Workers : guide Next.js
Source principale pour le chemin vinext actuellement recommandé, le contrôle de compatibilité et les liaisons Workers.
- Cloudflare Workers : adaptateur OpenNext
Source principale pour maintenir une application OpenNext existante et ses fonctionnalités Next.js prises en charge.
- Documentation Cloudflare D1
Source principale pour les liens D1, les données et les détails opérationnels.
- Documentation Cloudflare R2
Source principale pour le comportement du stockage d'objets, les limites et les liens de tarification.