tderoussel/ship-gate

Porte de livraison (Ship gate)

Toute règle ici existe parce que la vérification évidente a déjà renvoyé un faux positif. Exécutez la porte avant l'affirmation, pas après.

Adaptez les détails à votre pile ; la forme — qu'est-ce qui rendrait cette affirmation fausse ? — est la partie transférable.

La règle de l'affirmation

Une affirmation concernant la production nécessite une requête contre la production.

Un test réussi n'est pas la production. Une PR fusionnée n'est pas la production. Un déploiement vert n'est pas la production. Chacun de ces éléments est une affirmation concernant un système différent de celui sur lequel vous assertissez.

Si aucun humain n'a vérifié le résultat, ce n'est pas « vérifié » — dites ce que vous avez réellement vérifié à la place.

Vérification du déploiement

• Sachez ce qui déclenche réellement un déploiement. Sur un hébergeur intégré à Git, c'est le push, pas une invocation CLI. Déployer via CLI alors que le projet se déploie par push produit une build qui n'est pas celle que les utilisateurs reçoivent.
• Vérifiez le compte qui possède le projet. Une CLI connectée localement peut être authentifiée avec un compte personnel qui ne possède pas le projet de production — chaque commande réussit alors contre la mauvaise cible, silencieusement.
• Vérifiez avec le statut du commit par rapport au SHA déployé, pas un coup d'œil au tableau de bord.
• Confirmez que le déploiement est la production actuelle, pas simplement un qui est PRÊT. Plusieurs peuvent être prêts en même temps.
• Les fonctions Edge/serveur se déploient séparément de l'application. Une PR fusionnée ne déploie pas une fonction edge ; vérifiez sa version explicitement.
• Les modifications côté client peuvent ne nécessiter aucun déploiement de fonction — n'attendez pas un qui ne viendra jamais.
• Re-passez le manifeste en direct avant d'affirmer une version. Le travail parallèle augmente les versions en dessous de vous.

Vérification CI

• Portail sur tous les contextes requis, pas le premier vert.
• Ne jalousez jamais une commande pipeline. some-check | tail rapporte le code de sortie de tail, masquant la véritable erreur. Dans les shells sans PIPESTATUS (zsh diffère de bash ici), il est facile de se tromper — vérifiez le statut propre de la commande.
• steps: 0 signifie que le travail n'a jamais été exécuté, pas qu'il a réussi. Une API de vérifications peut rapporter une conclusion pour un travail qui n'a fait aucun travail.
• Un échec suspectement rapide sans étapes est généralement un problème de facturation ou d'autorisations, pas un problème YAML.
• Réexécuter uniquement les travaux échoués rejoue un instantané obsolète de la branche. Mettez d'abord la branche à jour, puis réexécutez.
• Une liste de vérifications omet les travaux qui n'ont jamais été créés. L'absence d'un échec n'est pas une preuve de réussite.
• gh pr create nécessite un --base explicite. Les heredocs chaînés autour de lui peuvent échouer silencieusement.

Portes de type et de lint

• Les grands projets TypeScript peuvent nécessiter un heap Node augmenté ; sans lui, tsc meurt d'une manière qui ressemble à une erreur de code.
• Sachez quels répertoires votre vérificateur de types et votre linter couvrent réellement. Les répertoires de fonctions edge sont fréquemment exclus des deux. S'ils s'exécutent sur un runtime différent, vérifiez-les avec le vérificateur propre de ce runtime — un travail de test n'est pas une porte de type.
• Construisez dans des worktrees ou des checkouts propres, pas dans un répertoire de travail avec des dérives non commitées.

Base de données

• Ne poussez jamais de schéma et n'exécutez jamais de migrations de manière occasionnelle contre la production. Appliquez le schéma via le chemin révisé que le projet a choisi, une fois.
• Appelez les nouvelles procédures stockées contre la base de données réelle avant de les croire. Les mocks cachent les erreurs d'exécution qui n'apparaissent qu'avec des types réels et une ambiguïté réelle.
• Si la suite de tests mocke la base de données de manière globale, un test unitaire réussi ne prouve rien sur la base de données.
• Ne jamais comparer-et-définir sur une colonne gérée par déclencheur — le déclencheur la modifie en dessous de l'écriture.
• Mesurez le rayon d'explosion d'un changement contre les données de production avant de fusionner. Un filtre qui semble étroit contre une graine locale peut correspondre à une part très différente des lignes réelles.

Pièges d'environnement

• Ne présumez jamais du fuseau horaire de la machine — utilisez date. Les tests dépendants de la date échouent sur le décalage, et l'échec ressemble à un bug de code.
• Une identité git non définie peut bloquer les déploiements et apparaître comme une erreur réseau non liée.
• Définissez les variables d'environnement de l'hôte à partir d'un fichier plutôt qu'avec une affectation en ligne ; les shells et les CLI peuvent intégrer des sauts de ligne qui corrompent la valeur de manière invisible.
• Le succès d'un travail planifié n'est pas le succès de son effet : un exécuteur rapportant « succès » signifie que l'invocation est revenue, pas que le travail a eu lieu. Vérifiez l'effet.

Sortie

État de chaque porte comme PASS (preuve) ou NON VÉRIFIÉ (pourquoi).

N'impliquez jamais qu'une porte a été exécutée quand elle ne l'a pas été. Si une porte échoue ou n'est pas vérifiée, dites clairement que le changement n'est pas vérifié — retenir l'affirmation est correct.