Una canalización de integración continua (CI) debe responder una pregunta concreta: ¿puede incorporarse este cambio a la base de código compartida sin introducir defectos conocidos ni romper los requisitos acordados? Para responderla, conviene definir comprobaciones repetibles, ordenar su ejecución y hacer que cada fallo aporte información útil.
CI no significa desplegar automáticamente cada cambio. Es la práctica de integrar cambios con frecuencia y validarlos de forma automatizada. La entrega continua prepara una versión desplegable de manera sostenida; el despliegue continuo añade la publicación automática en producción cuando se cumplen las condiciones establecidas. Una aplicación puede tener CI sin automatizar la entrega, o automatizarla hasta un entorno de pruebas y mantener una aprobación antes de producción.
Define el contrato de la canalización
Antes de elegir herramientas, especifica qué recibe la ejecución, qué debe producir y qué condiciones la hacen fallar. Una configuración útil documenta, como mínimo:
- Entradas: el cambio que se valida, la configuración pertinente y las dependencias declaradas por el proyecto.
- Entorno: sistema y requisitos de ejecución, configuración de PHP y servicios necesarios para las pruebas. Debe ser suficientemente parecido entre ejecuciones para que los resultados sean comparables.
- Resultado: estado final, informes de pruebas y análisis, y, cuando corresponda, un artefacto identificable que pueda validarse después.
- Condiciones de fallo: qué errores bloquean la integración, cuáles generan advertencias y quién puede aceptar una excepción temporal.
La instalación debe partir de la configuración de dependencias versionada y respetar el archivo de bloqueo, en lugar de resolver silenciosamente versiones nuevas en cada ejecución. Así se reduce una fuente de diferencias entre desarrolladores y CI. También hay que declarar los requisitos de plataforma y extensiones que la aplicación espera, y comprobar que el entorno de ejecución los satisface.
Evita que la canalización dependa de archivos locales, servicios personales o pasos manuales no documentados. Si una comprobación necesita base de datos, caché u otro servicio, define cómo se inicia, qué datos requiere y cómo se limpia. El contrato no tiene que imitar producción por completo, pero sí hacer explícitas las diferencias que puedan afectar al resultado.
Ordena las comprobaciones por coste y capacidad de detección
Una secuencia práctica empieza por las validaciones rápidas y termina con las que requieren más tiempo o infraestructura. La prioridad no es acumular tareas, sino detectar problemas cuanto antes sin perder cobertura significativa.
- Instalación reproducible: resuelve las dependencias a partir de la definición y el bloqueo del proyecto. Si falla, el resto de los resultados no es fiable.
- Formato y convenciones: verifica reglas de formato o estilo acordadas. Estas comprobaciones son rápidas y evitan que diferencias de presentación lleguen a una revisión más costosa.
- Análisis estático: busca incompatibilidades y errores detectables sin ejecutar todos los flujos de la aplicación. Ajusta las reglas al código y a la configuración real del proyecto.
- Pruebas: ejecuta primero las pruebas unitarias y añade pruebas de integración o de extremo a extremo según el riesgo que cubran y los servicios que necesiten.
- Validación del artefacto: comprueba que el paquete o imagen generado contiene lo necesario para ejecutarse y excluye archivos de desarrollo, datos locales y secretos.
No todas las aplicaciones necesitan las mismas pruebas ni el mismo orden. Si un análisis estático tarda mucho más que una prueba unitaria pequeña, puede convenir ejecutar ambas comprobaciones en paralelo tras instalar dependencias. Las tareas independientes también pueden ejecutarse en paralelo para reducir la espera, siempre que compartan una base reproducible y sus resultados queden asociados al mismo cambio.
En cambio, no conviene paralelizar a ciegas pasos que modifican el mismo directorio o dependen de resultados anteriores. Separa la preparación común de las tareas posteriores, limita la concurrencia de servicios compartidos y deja clara la dependencia entre etapas. El objetivo es acortar el feedback sin volver impredecible la canalización.
Decide qué bloquea y qué se ejecuta después
Como regla inicial, bloquea la integración cuando falla una comprobación relevante para la seguridad del cambio: instalación, análisis acordado, pruebas exigidas o validación del paquete. Una tarea informativa —por ejemplo, una comprobación todavía en evaluación— puede reportar resultados sin bloquear durante un periodo definido. Debe tener responsable, fecha de revisión y criterio para pasar a ser obligatoria; de lo contrario, las advertencias se vuelven permanentes y pierden valor.
Las comprobaciones rápidas deberían ofrecer feedback temprano en cada cambio. Las pruebas costosas pueden ejecutarse en paralelo, en una etapa posterior o con una frecuencia distinta si el tiempo o la infraestructura lo justifican. Sin embargo, reservar toda la validación importante para después de integrar deja una ventana en la que los cambios no han sido comprobados. Define qué se exige antes de integrar y qué queda como validación adicional, teniendo en cuenta el impacto de un fallo tardío.
Una ejecución correcta no equivale a un despliegue aprobado. CI verifica el cambio y puede generar un artefacto; el proceso de entrega decide cómo promoverlo, a qué entorno y bajo qué controles. Mantener explícita esta frontera evita que una tarea de validación publique accidentalmente en producción. Si existe despliegue automático, define por separado sus condiciones, aprobaciones, estrategia de exposición gradual y mecanismo de reversión.
Protege la configuración y los secretos
Los secretos no deben incorporarse al repositorio, a los archivos de configuración de ejemplo ni a los informes de ejecución. Usa el mecanismo de gestión de secretos del entorno de CI, limita su disponibilidad a las tareas que los necesitan y evita conceder credenciales de producción a validaciones que solo requieren servicios aislados.
Revisa también los registros: una excepción, una prueba fallida o una orden de diagnóstico puede imprimir variables sensibles. Enmascarar valores ayuda, pero no sustituye a evitar que se escriban. Usa datos de prueba que no expongan información real y define un procedimiento para revocar credenciales si aparecen en un registro o artefacto.
Haz que los fallos se puedan diagnosticar
Un estado rojo sin contexto obliga a repetir trabajo y convierte la CI en una caja negra. Conserva informes de pruebas y análisis, la salida necesaria para identificar el paso fallido y los identificadores de las versiones de dependencias o del artefacto. Evita, en cambio, registrar datos personales, secretos o volcados indiscriminados del entorno.
Cuando una prueba falla de forma intermitente, no la marques como exitosa tras reintentar sin límite. Registra qué pruebas fluctúan, con qué frecuencia y en qué condiciones; investiga causas como concurrencia, dependencias externas, estado compartido o límites de tiempo. Si se aísla temporalmente una prueba inestable, documenta el riesgo, asigna una persona responsable y fija una fecha para restablecer su carácter bloqueante.
También conviene distinguir un fallo del código de un problema de infraestructura. Informa si no se pudieron iniciar servicios, obtener dependencias o completar una tarea por falta de recursos. Un reintento puede ser razonable ante una interrupción transitoria, pero debe ser limitado y visible; ocultar el primer fallo dificulta detectar problemas recurrentes.
Adapta la CI a una aplicación heredada
En un sistema antiguo, activar de golpe reglas estrictas puede bloquear cambios útiles y fomentar excepciones sin control. Empieza con una línea base: identifica qué pruebas pasan hoy, qué errores preexistentes reporta el análisis y cuánto tarda cada etapa. No presentes como regresión un problema que ya existía, pero tampoco permitas que la línea base se convierta en una excusa indefinida.
- Haz obligatorias primero las comprobaciones reproducibles que ya sean estables, como la instalación y un conjunto fiable de pruebas.
- Registra los hallazgos existentes y exige que los cambios nuevos no amplíen el problema, si la herramienta y el proyecto permiten esa comparación.
- Añade pruebas alrededor de las áreas con mayor riesgo de cambio y amplía su cobertura gradualmente.
- Reduce excepciones en cambios pequeños y revisables; asigna responsable y fecha a cada excepción temporal.
- Mide el tiempo y las causas de fallo para optimizar etapas concretas, en lugar de eliminar validaciones sin saber qué riesgo cubrían.
Una buena integración continua en PHP no se define por la cantidad de etapas, sino por resultados repetibles y comprensibles. Si el equipo puede explicar qué valida cada paso, qué bloquea la integración y cómo investigar un fallo, la canalización ayuda a decidir con evidencia cuándo un cambio está listo para avanzar.
