Integración Continua

La Integración Continua es ampliamente malinterpretada. No es solo un servidor de compilación. No es solo ejecutar pruebas en cada commit. Esas son herramientas que apoyan CI—pero CI en sí es una práctica.

CI real significa:

• Todos hacen commit a la rama principal (o trunk) al menos diariamente
• Cada commit activa una compilación y ejecución de pruebas
• Si la compilación falla, arreglarla es la máxima prioridad
• La rama principal siempre está en un estado desplegable

La parte "continua" es clave. Si estás integrando semanalmente, eso no es continuo. Si tienes ramas de funcionalidad de larga duración, eso no es continuo. CI significa integrar tu trabajo con el trabajo de todos los demás cada día, usualmente varias veces al día.

La verdadera CI requiere desarrollo basado en trunk: todos hacen commit a la rama principal (a menudo llamada "trunk" o "main").

Esto suena aterrador. ¿No romperá la gente cosas? Ahí es donde entra la disciplina:

• Ejecuta pruebas antes de hacer commit (no rompas la compilación)
• Haz commit de cambios pequeños (más fácil de integrar, más fácil de arreglar)
• Arregla compilaciones rotas inmediatamente (todos se detienen hasta que esté en verde)
• Usa feature flags para funcionalidades incompletas (para que puedan fusionarse pero no activarse)

Las ramas de larga duración son el enemigo de CI. Cuando desarrollas en una rama durante semanas, no estás integrando. Solo estás posponiendo la integración—y mientras más esperes, más difícil se vuelve.

Crea ramas por horas, no por días. Integra diariamente, no semanalmente.

Para que CI funcione, el ciclo de compilación y pruebas debe ser rápido. Martin Fowler sugiere la regla de los 10 minutos: toda la compilación, incluyendo todas las pruebas, debe completarse en menos de 10 minutos.

¿Por qué 10 minutos? Porque:

• Los desarrolladores necesitan retroalimentación rápida sobre sus cambios
• Esperar una hora para saber si rompiste algo es demasiado lento
• Las compilaciones largas alientan a los desarrolladores a omitir ejecutar pruebas localmente

Si tu compilación toma demasiado tiempo:

• Paraleliza las pruebas
• Usa hardware más rápido
• Optimiza las pruebas más lentas
• Considera categorización de pruebas (pruebas unitarias rápidas vs pruebas de integración lentas)
• Revisa el diseño de pruebas (¿demasiada base de datos? ¿demasiada red?)

Algunos equipos ejecutan un subconjunto rápido localmente (pruebas unitarias) y la suite completa en el servidor CI. Eso está bien siempre que la suite completa se ejecute lo suficientemente rápido para proporcionar retroalimentación oportuna.

La compilación fallará. Lo que importa es qué sucede después.

La regla: Cuando la compilación falla, arreglarla se convierte en la máxima prioridad. Todo lo demás se detiene.

Esto puede parecer extremo, pero considera: una compilación rota significa que el equipo no puede confiar en la rama principal. El trabajo de todos está bloqueado porque no pueden integrar de manera segura. Cada minuto que la compilación está rota es un minuto de riesgo acumulado.

¿Quién la arregla? Usualmente la persona que la rompió. Pero si está atascada, otros ayudan. Una compilación rota es un problema del equipo, no un problema individual.

Cómo prevenir fallas:

• Ejecuta pruebas localmente antes de hacer commit
• Mantén los cambios pequeños (cambios más pequeños = menor riesgo)
• Presta atención a las notificaciones de CI (arregla rápido)
• No hagas commit y te vayas del día

Algunos equipos usan una rotación de "sheriff de CI"—alguien responsable de vigilar la compilación y coordinar arreglos. Esto previene el efecto espectador donde todos asumen que alguien más lo arreglará.

CI es la base para prácticas más avanzadas:

Entrega Continua (CD): Cada commit puede desplegarse a producción. El despliegue es una decisión de negocio, no técnica.

Despliegue Continuo: Cada commit que pasa las pruebas se despliega automáticamente a producción. No se requiere aprobación humana.

No todos los equipos necesitan despliegue continuo. Pero todos los equipos se benefician de CI. Comienza ahí.

Métricas de CI a vigilar:

• Tiempo de compilación (debe ser menor a 10 minutos)
• Frecuencia de compilación (debe ser varias veces al día por desarrollador)
• Tiempo medio para arreglar compilaciones rotas (debe ser minutos, no horas)
• Cobertura de pruebas (no es una métrica perfecta, pero es una señal)

CI no se trata solo de atrapar bugs. Se trata de crear un ritmo donde la integración es aburrida, rutinaria y segura. Cuando la integración es segura, todo lo demás se vuelve más fácil.