Tu API puede tener DTOs perfectamente tipados, una suite completa de Pest y Response Wrappers que nunca se desvían, y nada de eso importa hasta que el código corre en un sitio al que tus usuarios pueden llegar. El despliegue es donde la teoría se encuentra con la realidad. El FormRequest que validaba limpiamente en tu portátil tiene que sobrevivir a una migración corriendo contra una base de datos que aún sirve tráfico en vivo. El worker de cola que procesaba jobs correctamente en tus pruebas tiene que seguir procesándolos mientras publicas justo el código que cambia la definición de esa clase de job.
Este capítulo cubre cómo es publicar una vez pasado el pull request: una tubería que bloquea el código malo antes de que un servidor lo vea, un despliegue que no tira peticiones mientras ocurre, migraciones seguras de ejecutar contra un esquema que la versión anterior todavía lee, un plan de reversión en el que creas de verdad a las dos de la mañana, secretos que viven fuera de tu repositorio y un aprovisionamiento que puedes repetir sin releer tus propias notas de hace seis meses.
Un despliegue durante el que tienes que contener la respiración es un despliegue que no has terminado de diseñar.
Una tuberia que rechaza el codigo malo
¿Por qué poner comprobaciones delante de un despliegue en lugar de confiar en que cada persona las ejecute antes en local? Porque las personas se olvidan y la integración continua no.
Todas las aplicaciones actuales de esta flota definen los mismos tres scripts de composer: format, check y test.
// composer.json
{
"scripts": {
"format": [
"./vendor/bin/pint"
],
"check": [
"./vendor/bin/phpstan analyse --memory-limit=2G"
],
"test": [
"./vendor/bin/pest"
]
}
}
format ejecuta Pint y corrige el estilo automáticamente. check ejecuta PHPStan: no arregla nada, simplemente se niega a pasar si tus tipos no cuadran. Cuatro de las cinco aplicaciones lo configuran a nivel 9, el más estricto; merchants corre a nivel 5. Incluso dentro de una flota tan disciplinada como para compartir un nombre de comando, el número detrás de ese comando no es automáticamente el mismo en todas partes, y nadie impone que lo sea. test ejecuta la suite de Pest.
Una tubería, la ejecute quien la ejecute, no necesita reinventar esto. Corre los mismos tres comandos que corre una persona en local, con un ajuste: composer format -- --test en lugar de un composer format pelado —la bandera de Pint para fallar ante violaciones de estilo en vez de reescribir en silencio ficheros que un runner no tiene por qué confirmar—, luego composer check y luego composer test. Si alguno sale con código distinto de cero, la construcción está en rojo y nada posterior llega a ejecutarse.
Esa última parte es todo el asunto. Quien olvida ejecutar PHPStan antes de subir no tiene una segunda oportunidad de acordarse: la tubería se acuerda por esa persona. Es la misma disciplina que este libro defiende desde el capítulo 1, sólo que aplicada a la frontera entre tu repositorio y producción en lugar de a la frontera entre una petición y tu controlador: valida en el borde, falla en voz alta y nunca dejes que la entrada mala viaje más lejos de lo necesario. Aquí, la «entrada mala» es código que no pasa la comprobación de tipos o no pasa sus propias pruebas.