Capítulo 7: Día 3 - Integración continua real
Capítulo 7: Día 3 — Integración continua real
Miércoles. Diego y Elena han trabajado en paralelo: él en el backend, ella en el frontend. Cuando ambos intentan integrar su trabajo, chocan. Es el primer conflicto de merge del proyecto y el momento donde la integración continua demuestra su valor.
Anterior: Día 2: Feedback temprano | Siguiente: Primer Small Release
El conflicto
Elena termina su parte del frontend temprano y empuja al repositorio. CI verde. Diego termina su parte del backend y empuja. CI rojo.
Diego (Dev): “¿Qué pasó? En mi máquina todo funciona.”
Carlos (TL): “Mira el error. Elena modificó la estructura de datos que compartían para la tarjeta. Tú todavía usas la versión anterior.”
Diego (Dev): “Pero yo no toqué eso…”
Carlos (TL): “No, pero dependías de ello. Este es un conflicto de integración. Es normal. Lo importante es que lo descubrimos en minutos, no en semanas.”
Diego mira el error con frustración. Elena se acerca.
Elena (Dev): “¿Rompí algo tuyo?”
Diego (Dev): “No es culpa tuya. Es que ambos tocamos la definición de la tarjeta sin coordinarnos.”
Carlos (TL): “Y eso es exactamente por qué integramos seguido. Si hubieran esperado al viernes para integrar, este conflicto habría involucrado diez archivos en vez de uno."
"Si duele, hazlo más seguido”
Carlos aprovecha el momento para enseñar uno de los principios más contra-intuitivos de XP.
Carlos (TL): “Kent Beck dice: si algo duele, hazlo más seguido. Parece absurdo, pero la lógica es sólida. Si integrar duele, es porque lo haces poco. Cada vez que no integras, la distancia entre tu código y el de tu compañero crece. Cuanto más crece, más duele cuando finalmente juntan todo.”
Elena (Dev): “Entonces la solución no es evitar integrar…”
Carlos (TL): “La solución es integrar tan seguido que cada integración sea trivial. Mi regla: mínimo dos veces al día. Idealmente cada vez que completas un ciclo de red-green-refactor significativo.”
Diego (Dev): “¿Cada hora?”
Carlos (TL): “Si los tests pasan y CI está verde, ¿por qué no? Cada empujón al repositorio es un checkpoint de seguridad.”
Resolviendo el conflicto juntos
Diego y Elena se sientan juntos para resolver el conflicto. Carlos observa.
Diego (Dev): “Elena cambió el nombre de un campo. Tiene sentido el nuevo nombre. Solo necesito actualizar mis referencias.”
Elena (Dev): “Debí haber avisado antes de cambiar eso.”
Carlos (TL): “O mejor: debieron haber integrado antes. Si Elena hubiera empujado una hora antes y Diego hubiera actualizado su rama, el conflicto no habría existido.”
Diego (Dev): “Lección aprendida.”
Resuelven el conflicto en diez minutos. Empujan. CI verde. Lo que podría haber sido un drama de medio día fue un bache de diez minutos.
Cambiando parejas a mediodía
Después del almuerzo, Carlos propone cambiar las parejas.
Carlos (TL): “Elena, haces pair con Diego esta tarde. El frontend necesita conectarse con el backend. Quién mejor que ambos para hacerlo juntos.”
Diego (Dev): “¿Y tú?”
Carlos (TL): “Voy a revisar que nuestra estructura de tests siga las convenciones y a hablar con Ana sobre la demo del viernes.”
Diego y Elena se sientan juntos. Esta vez Diego navega y Elena conduce. Están conectando la pantalla de React con la API de FastAPI.
Diego (Dev): “Ahí. Ese endpoint devuelve los datos que necesitas.”
Elena (Dev): “Perfecto. Hago la llamada y muestro las tarjetas en la columna correspondiente.”
Diego (Dev): “¿Y el botón de mover?”
Elena (Dev): “Primero muestro datos. Después el botón. Un paso a la vez.”
Múltiples integraciones en un día
El equipo empuja al repositorio cuatro veces durante la tarde. Cada vez los tests pasan. Cada vez CI se pone verde. Cada integración toca dos o tres archivos como máximo.
Elena (Dev): “Es verdad que cada integración pequeña no duele nada.”
Diego (Dev): “Comparado con esta mañana, donde acumulamos medio día de trabajo sin integrar.”
Carlos (TL): “¿Ven? El dolor de esta mañana fue pedagógico. No lo provocamos a propósito, pero aprendimos la lección.”
Ana pasa por la zona del equipo al final del día.
Ana (PO): “¿Cómo van?”
Elena (Dev): “La pantalla ya muestra las tarjetas. Mañana agregamos el botón de mover.”
Ana (PO): “¿Puedo verlo?”
Elena (Dev): “Claro.”
Elena le muestra la pantalla. Es básica: un tablero con columnas y nombres de tarjetas. Sin estilos bonitos. Sin animaciones. Pero Ana puede ver datos reales.
Ana (PO): “Es feo pero funcional. Me encanta.”
Carlos (TL): “Esa es la mejor reseña que un equipo XP puede recibir.”
Práctica XP del capítulo
Continuous Integration: En XP, integración continua no es solo una herramienta (CI/CD). Es una disciplina. Significa que cada miembro del equipo integra su trabajo con el del resto varias veces al día. Kent Beck argumenta que la integración infrecuente es una de las fuentes principales de dolor en el desarrollo de software. Al integrar constantemente, los conflictos son pequeños, predecibles y fáciles de resolver. El pipeline de CI es solo el mecanismo que verifica automáticamente que la integración fue exitosa.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Ve progreso visual por primera vez, da feedback positivo |
| Carlos | Enseña principios de CI, revisa estructura de tests |
| Diego | Resuelve conflicto con Elena, navega en pair |
| Elena | Resuelve conflicto con Diego, conduce en pair |
Anterior: Día 2: Feedback temprano | Siguiente: Primer Small Release