tderoussel/ship-gate

Ship gate (Puerta de envío)

Cada regla aquí existe porque la comprobación obvia devolvió un falso pase en algún momento. Ejecuta la puerta antes de la afirmación, no después.

Adapta los detalles a tu stack; la forma — ¿qué haría que esta afirmación fuera falsa? — es la parte transferible.

La regla de la afirmación

Una afirmación sobre producción requiere una consulta contra producción.

Una prueba que pasa no es producción. Un PR fusionado no es producción. Un despliegue verde no es producción. Cada uno de esos es una afirmación sobre un sistema diferente al que estás afirmando.

Si ningún humano ha visto el resultado, no está "verificado" — di lo que realmente comprobaste en su lugar.

Verificación de despliegue

• Sepa qué desencadena realmente un despliegue. En un host integrado con git, es el push, no una invocación de CLI. Desplegar por CLI cuando el proyecto despliega por push produce una compilación que no es la que los usuarios reciben.
• Verifique la cuenta que posee el proyecto. Un CLI iniciado sesión localmente puede estar autenticado como una cuenta personal que no posee el proyecto de producción — cada comando entonces tiene éxito contra el destino equivocado, en silencio.
• Verifique con el estado del commit contra el SHA desplegado, no un vistazo al dashboard.
• Confirme el despliegue que es producción actual, no meramente uno que está LISTO. Varios pueden estar listos a la vez.
• Las funciones edge/serverless se despliegan por separado de la aplicación. Un PR fusionado no despliega una función edge; verifica su versión explícitamente.
• Los cambios solo de cliente pueden no necesitar un despliegue de función — no esperes uno que nunca llegará.
• Vuelve a obtener el manifiesto en vivo antes de afirmar una versión. El trabajo paralelo incrementa las versiones por debajo de ti.

Verificación de CI

• Filtra por cada contexto requerido, no solo el primero verde.
• Nunca filtres por un comando canalizado. some-check | tail reporta el código de salida de tail, ocultando la falla real. En shells sin PIPESTATUS (zsh difiere de bash aquí), es fácil equivocarse — verifica el estado propio del comando.
• steps: 0 significa que el trabajo nunca se ejecutó, no que pasó. Una API de comprobaciones puede reportar una conclusión para un trabajo que no hizo nada.
• Una falla sospechosamente rápida sin pasos suele ser un problema de facturación o permisos, no un problema de YAML.
• Re-ejecutar solo trabajos fallidos reproduce una instantánea obsoleta de la rama. Actualiza la rama primero, luego re-ejecuta.
• Una lista de comprobaciones omite trabajos que nunca se crearon. La ausencia de una falla no es evidencia de un pase.
• gh pr create requiere un --base explícito. Los heredocs encadenados alrededor de él pueden fallar en silencio.

Gates de tipo y lint

• Los proyectos grandes de TypeScript pueden necesitar un heap de Node aumentado; sin él tsc muere de una manera que parece un error de código.
• Sepa qué directorios cubren realmente su verificador de tipos y linter. Los directorios de funciones edge están frecuentemente excluidos de ambos. Si se ejecutan en un runtime diferente, verifíquelos con el verificador propio de ese runtime — un trabajo de prueba no es un gate de tipo.
• Compile en worktrees o checkouts limpios, no en un directorio de trabajo con deriva no confirmada.

Base de datos

• Nunca empujes esquemas ni ejecutes migraciones casualmente contra producción. Aplica el esquema a través de la ruta revisada que el proyecto ha elegido, una vez.
• Llama a nuevos procedimientos almacenados contra la base de datos real antes de creerlos. Los mocks ocultan errores de tiempo de ejecución que solo aparecen con tipos reales y ambigüedad real.
• Si la suite de pruebas simula la base de datos globalmente, una prueba unitaria que pasa no prueba nada sobre la base de datos.
• Nunca hagas comparar-y-establecer en una columna gestionada por disparadores — el disparador la cambia por debajo de la escritura.
• Mide el radio de explosión de un cambio contra datos de producción antes de fusionar. Un filtro que parece estrecho contra una semilla local puede coincidir con una proporción muy diferente de filas reales.

Trampas ambientales

• Nunca asumas la zona horaria de la máquina — ejecuta date. Las pruebas dependientes de fecha fallan en el desfase, y la falla parece un error de código.
• Una identidad git no configurada puede bloquear despliegues y aparecer como un error de red no relacionado.
• Establece variables de entorno de host desde un archivo en lugar de asignación en línea; los shells y CLIs pueden incrustar saltos de línea finales que corrompen el valor invisiblemente.
• El éxito de un trabajo programado no es éxito del efecto del trabajo: un runner que reporta succeeded significa que la invocación retornó, no que el trabajo sucedió. Verifica el efecto.

Salida

Estado cada gate como PASS (evidencia) o NOT CHECKED (por qué).

Nunca impliques que un gate se ejecutó cuando no lo hizo. Si algún gate falla o no está verificado, di claramente que el cambio no está verificado — retener la afirmación es correcto.