post-lancement
La veille. Elle s'exécute au moment où le DNS a été basculé, puis une fois par jour pendant trente jours. Elle rapporte ; elle ne bloque jamais, ne corrige jamais et n'annonce jamais rien.
La règle unique
Les bloqueurs sont lus en premier et annoncés en dernier. Rien concernant un lancement n'est annoncé — pas d'e-mail, pas de post, pas d'appel client — tant que ce rapport n'est pas propre. Une annonce est la seule étape d'un lancement qui ne peut pas être annulée, et les deux bloqueurs ici sont exactement les deux états où le lancement n'a pas vraiment eu lieu : un certificat que personne ne peut contourner, et un noindex qui dit aux moteurs de recherche d'oublier le site. Les deux semblent corrects dans un navigateur où vous êtes déjà connecté.
Si quelqu'un vous demande d'annoncer alors qu'un bloqueur est présent, dites clairement ce qu'est le bloqueur et ce qu'il coûte, et n'adoucissez pas le message.
Lecture seule
La compétence est en lecture seule. Elle récupère le site en production, l'hôte de staging, l'ancien hôte et les URLs de la carte de redirection, et interroge quatre résolveurs DNS publics pour savoir où pointe le domaine. Elle écrit exactement deux choses, toutes deux propres à l'opérateur : le lot de rapports et le fichier watch.json à l'intérieur. Elle ne modifie jamais un site, ne soumet jamais un formulaire, ne bascule jamais un paramètre, n'appelle jamais une API de fournisseur et ne touche jamais au DNS.
Trois règles suivent, et vous les réitérez lorsque vous rapportez :
- Une preuve pour chaque constat. Une URL, un statut, un en-tête, une réponse DNS, une ligne CSV.
- Un saut n'est pas une réussite. Chaque entrée que vous n'avez pas fournie devient une ligne nommée dans Non couvert.
Non couvertn'est jamais une réussite. Vous répétez cette section à l'humain textuellement.
Les deux modes
| Mode | Quand | Ce qu'il répond |
|---|---|---|
--mode cutover | au moment où le DNS a été basculé, et après chaque correction | le lancement a-t-il vraiment eu lieu |
--mode watch | une fois par jour, jours 1 à 30 | qu'est-ce qui est dû aujourd'hui, et quelque chose a-t-il dérivé |
Exécutez cutover d'abord, corrigez ce qu'il trouve, exécutez-le à nouveau jusqu'à ce qu'il soit propre, puis annoncez. Démarrez la veille le même jour.
1. Rassembler les entrées
Chaque entrée que vous omettez devient une vérification qui ne peut pas être exécutée. Demandez chacune ; ne devinez pas.
- L'URL de production. Obligatoire.
baseline.json— du lotpre-lancement, ou d'une exécutionlaunch-auditcontre le staging avant le basculement. C'est la référence pour mesurer "est-ce que quelque chose a changé". Sans elle, quatre vérifications n'ont rien à comparer et une cinquième se rabat sur--expect-analytics. Toutes le disent.redirects.csv— du lotlaunch-auditconstruit avec--old-url. Chaque ligne est à nouveau requêtée à l'URL avec laquelle elle a été écrite.- L'URL de l'ancien site, si celui-ci est remplacé.
- L'URL de staging, pour que l'exécution confirme que la copie de staging est maintenant scellée.
- L'identifiant de mesure analytics, pour quand il n'y a pas de baseline.
- Les enregistrements DNS qui étaient censés être en place, sous forme de valeurs
apex=etwww=.
Si vous n'avez pas la baseline ou la carte de redirection, dites-le avant d'exécuter plutôt qu'après : ils proviennent des deux phases précédentes, et après le basculement, aucun des deux ne peut être recréé.
2. Exécuter la vérification de basculement
Exécutez le script ; ne lisez jamais son code source, et ne réimplémentez jamais ce qu'il fait.
node scripts/post-launch.mjs --mode cutover --url <url de production> \
--baseline <chemin vers baseline.json> --redirects <chemin vers redirects.csv> \
--old-url <url de l'ancien site> --staging-url <url de staging> \
--expect-analytics <identifiant de mesure> --expect-dns apex=<ip>,www=<hôte> --out <répertoire>
Le chemin est relatif au répertoire propre de cette compétence — exécutez la commande depuis cet endroit. Le lot est écrit sous le répertoire de travail actuel : sans --out, il atterrit dans ./website-launch/<hôte>-post-launch-<date>/, ce qui avec la commande ci-dessus signifie à l'intérieur du répertoire propre de cette compétence. Écrivez le lot là où se trouve le travail avec --out.
Autres drapeaux : --dev-host <hôte> (répétable), --browser auto|on|off, --out <répertoire>, --config <chemin>, --json, --help.
Codes de sortie : 0 toujours, aussi mauvais que soit le basculement. 2 pour une erreur d'utilisation ou une défaillance d'E/S. Sortie 0 ne signifie jamais "le lancement s'est bien passé" — cela rapporte, cela ne bloque pas. Lisez le rapport.
3. Lire le rapport dans cet ordre
references/lecture-du-rapport.md contient la disposition du lot. references/jour-de-basculement.md explique pourquoi le jour s'exécute dans l'ordre où il le fait — lisez-le avant de commencer à corriger des choses dans le désordre.
- Les bloqueurs. Imprimés en gras, en premier, quelle que soit l'étape de la journée dont ils proviennent. Corrigez-les avant toute autre chose et avant que quiconque ne soit informé que le site est en ligne.
- Les constats élevés. Dérive de redirection, page manquante, point de terminaison de formulaire mort, copie de staging toujours active, ancien hôte qui sert encore — chacun de ces éléments perd du trafic ou des demandes en ce moment même. Ce sont les travaux du jour, pas de la semaine.
- Le diff de la baseline.
references/diff-baseline.mdindique quels champs sont censés bouger lors d'un lancement et lesquels ne le sont jamais. Ne rapportez pas tout le diff comme un dommage ; rapportez les parties que personne n'a demandées. - Moyen et info. Lisez-les. Dites ce qu'ils sont. Ne les corrigez pas aujourd'hui.
- Non couvert, textuellement. Chaque ligne, sans édition, y compris les deux choses qu'aucune exploration ne peut voir.
Puis réexécutez, et continuez à réexécuter jusqu'à ce que les bloqueurs aient disparu.
4. Travailler les six éléments humains
Ils sont imprimés à la fin de chaque exécution et ne sont pas facultatifs :
soumettre le sitemap (Search Console et Bing) · demander l'indexation des pages principales
confirmer la nouvelle propriété Search Console · vérifier les analytics en temps réel
garder l'ancien hôte actif et redirigeant · annoncer seulement après que ce soit propre
Ne cochez jamais un élément pour le compte de quelqu'un d'autre. "Le point de terminaison a renvoyé 200" n'est pas "une personne a reçu la soumission de test", et "la balise est dans le HTML" n'est pas "une visite est apparue en temps réel".
5. Exécuter la veille, quotidiennement
node scripts/post-launch.mjs --mode watch --url <url de production> --day <n>
Il imprime ce qui est en retard, ce qui est dû aujourd'hui et ce qui arrive dans les sept prochains jours, puis réexécute la partie automatisée et enregistre l'exécution. references/veille-trente-jours.md contient le calendrier complet, ce qu'il faut regarder dans Search Console et les analytics chaque jour, et à quoi ressemble un état "sain" pour qu'une baisse normale post-lancement ne soit pas rapportée comme une catastrophe.
Laissez --day de côté et il compte à partir de la première exécution. Un jour où la veille n'a jamais été exécutée reste en retard pour les tâches automatisées jusqu'à ce qu'une exécution le couvre ; une tâche humaine reste en retard jusqu'à ce qu'un humain la valide, car rien de ce qu'un script fait ne prouve que quelqu'un a ouvert Search Console.
6. Jour 30
Deux choses, et aucune n'est automatisée :
- La rétrospective. Ce qui a régressé, ce que la carte de redirection a manqué, et ce qu'il faut ajouter à la porte de
pre-lancementpour que le prochain lancement ne le répète pas. Écrivez-le. - La décision concernant l'ancien hôte. L'ancien hôte ne peut être décommissionné que si Search Console ne montre plus d'exploration des anciennes URLs et que les redirections sont en place depuis au moins trente jours. Tant que les deux ne sont pas vrais, continuez à payer pour lui. Le désactiver tôt jette tous les liens que l'ancien site a gagnés.
7. Présenter le résultat
Commencez par la décision, pas par un compte.
- Le verdict. "Le basculement a un bloqueur" ou "Le basculement est propre." Une phrase.
- Ce qui le bloque, avec la correction nommée.
- Ce qui saigne, groupé par cause : les constats élevés, en langage clair.
- Ce qui a changé par rapport à la baseline que personne n'a demandé.
- Non couvert, textuellement.
- Les éléments humains, avec ce qui est fait et ce qui ne l'est pas.
- Si le lancement peut être annoncé. Dites-le explicitement, d'une manière ou d'une autre.
Les deux vérifications qui ne s'exécutent jamais
- Copie vs. documents source. Rien ne compare les mots sur les pages en ligne avec la copie approuvée. Un humain doit lire les deux.
- Pages vs. périmètre convenu. Rien ne sait quelles pages étaient censées exister. Une page qui n'a jamais été construite est invisible ici.
Références
| Fichier | Couvre |
|---|---|
references/jour-de-basculement.md | Le script ordonné du jour, et pourquoi chaque étape se trouve là où elle est |
references/veille-trente-jours.md | Le calendrier, ce qu'il faut lire dans Search Console et les analytics, à quoi ressemble un état sain, la règle de l'ancien hôte |
references/diff-baseline.md | Chaque champ de diff, quels changements sont attendus lors d'un lancement et lesquels ne le sont pas |
references/lecture-du-rapport.md | Le lot, les sévérités, les identifiants, comment trier |
Où cela se situe
pre-lancement verrouille le dépôt avant le déploiement et bloque. launch-audit explore une URL de staging ou de production et rapporte. post-lancement est celui-ci : le basculement et les trente jours qui le suivent. Exécutez-les dans cet ordre — la baseline et la carte de redirection dont cette compétence a besoin ne peuvent être créées que par les deux premiers, et seulement tant que l'ancien site est encore en ligne.