Ship Cloudflare Sites v1.1

Que fait Ship Cloudflare Sites v1.1 ?

Opérez à partir des preuves du dépôt et du périmètre demandé par l'utilisateur. Une demande de déploiement autorise le workflow de déploiement ordinaire pour l'environnement nommé ; ne posez de question que lorsqu'un changement supplémentaire destructeur, irréversible ou matériellement plus large devient nécessaire. N'inférez jamais une cible de production à partir d'un environnement non spécifié.

Découvrir le projet

1. Lisez les instructions du dépôt et inspectez l'arborescence de travail actuelle avant d'éditer.
2. Exécutez scripts/audit-cloudflare-project.sh <project-root> et inspectez chaque bloqueur signalé.
3. Résolvez le framework, le gestionnaire de paquets, l'adaptateur, l'entrée Worker, la configuration Wrangler, les environnements, les bindings, les migrations, les domaines, le chemin CI et les noms de secrets à partir des fichiers — pas de mémoire.
4. Utilisez le CLI épinglé par le dépôt. Vérifiez le comportement mutable de Cloudflare/OpenNext dans le --help local et la documentation officielle actuelle avant les changements distants.
5. Lisez uniquement les références pertinentes :
   • Lisez references/release-workflow.md pour la release, le rollback ou l'itération de version.
   • Lisez references/cloudflare-resources.md pour provisionner ou modifier D1, R2, secrets, domaines, mise en cache, environnements ou observabilité.

Choisir le mode de fonctionnement

• Audit/plan : restez en lecture seule. Renvoyez les preuves, bloqueurs, risques et actions suivantes exactes.
• Développer/configurer : éditez et vérifiez localement. Créez des ressources distantes uniquement lorsque l'utilisateur a demandé un provisionnement ou que le déploiement les requiert.
• Provisionner : confirmez le compte, la zone, l'environnement, les noms et la propriété prévue ; créez uniquement les ressources manquantes et persistez les ID retournés dans la configuration choisie.
• Publier : compilez une fois, puis déployez cet artefact vérifié. Utilisez un déploiement direct pour les releases à faible risque lorsqu'elles sont demandées ; utilisez le téléchargement de version plus la promotion contrôlée pour les releases risquées ou explicitement progressives.
• Restaurer : sélectionnez une version Worker connue comme bonne, puis gérez séparément l'état D1 et R2. Les versions Worker ne contiennent pas l'état de stockage.

Appliquer les gardes invariantes

• Distinguez les ressources locales, preview/staging et production. Rendez explicite la cible de chaque commande distante.
• Gardez les valeurs secrètes hors du code source, de la sortie, des captures d'écran et des arguments shell. Rapportez uniquement les noms et leur présence.
• Examinez un arbre de travail sale avant une release. Ne jetez pas, ne commitez pas et ne livrez pas les modifications utilisateur non liées.
• Modélisez les modifications D1 comme des migrations ordonnées et préférez l'approche extend/backfill/contract entre les releases.
• Utilisez des clés R2 immuables ou versionnées pour les actifs à longue mise en cache. Traitez l'écrasement, la suppression, le changement CORS et la purge de cache comme un seul changement coordonné.
• Traitez les domaines personnalisés Worker et les domaines personnalisés R2 comme des ressources distinctes. Vérifiez indépendamment l'apex, www, les redirections canoniques, les certificats et le nom d'hôte des actifs.
• N'appelez pas un téléchargement une release réussie. Vérifiez le nom d'hôte public, les routes critiques, le comportement basé sur D1, un objet R2 représentatif et les logs post-déploiement.

Produire un enregistrement de release

Retournez :

• l'ID de release, le commit Git, l'environnement, les noms des ressources Worker et de stockage ;
• les modifications source/configuration livrées et les modifications de l'arbre de travail exclues ;
• les portes locales et leurs résultats ;
• les migrations D1 plus le marque-page/export de récupération et l'ordre de compatibilité ;
• les modifications R2/domaine/cache/secret sans les valeurs secrètes ;
• l'ID de version/déploiement Worker et le pourcentage de trafic lorsqu'il est disponible ;
• les URL et résultats des tests de fumée ;
• la cible de rollback, les mises en garde sur le stockage et les actions manuelles restantes.

Si une porte échoue, arrêtez-vous avant la frontière non sécurisée, conservez les preuves et indiquez ce qui reste. N'affaiblissez pas une porte silencieusement.