Description: Build, Cloudflare Workers et déploiement : comprendre le piège d'une automatisation qui valide le vide.
Introduction
Mettre un site à jour devrait être simple. Pourquoi attendre quarante minutes pour retrouver exactement l'ancienne page ? Le problème vient parfois moins de la fabrication des fichiers que des contrôles accumulés avant la mise en ligne.
What is happening?
Le build transforme les articles et le code en fichiers utilisables par le navigateur. Cloudflare Workers répond aux visiteurs et peut exécuter du code. GitHub Actions et Buildkite lancent les commandes de construction et de publication. Si l'on appelle tout cela « le Worker est arrêté », le diagnostic devient flou.
The absurd failure
Imaginez un déploiement qui demande d'abord l'autorisation à un Worker, passe au code le plus récent, relance la tâche, vérifie les changements, consulte un registre de quotas gratuits, puis produit un rapport. La première vérification expire parce que le quota est épuisé. Le système l'ignore, se bloque à la suivante et ne publie rien. Le tableau de bord affiche pourtant SUCCÈS. C'est le livreur qui confirme la livraison sans avoir quitté l'entrepôt.
How to tell what failed
Cent erreurs rouges peuvent venir d'un seul fichier commun. À l'inverse, un build réussi ne garantit pas que le site public a changé. Il faut distinguer trois preuves : les fichiers ont été produits, ils ont été envoyés et l'adresse publique affiche bien la nouvelle version.
A simpler route
Une solution plus simple consiste à utiliser une commande officielle pour publier le Worker et une autre pour construire et envoyer le site. Tous les outils appellent ces mêmes commandes. Une publication sautée doit être signalée comme un échec, puis la version en ligne doit être vérifiée.
Conclusion
L'automatisation devait nous libérer du travail répétitif. Elle a fini par exiger sa propre équipe de baby-sitters. La meilleure amélioration consiste parfois à supprimer des barrières.
