El futuro de la integración continua
Hace unos días estaba leyendo de nuevo el libro "Continuous integration" de Paul Duvall. Creo que es una lectura muy interesante, especialmente si usas métodos ágiles.
El libro es de mediados de 2007, así que es bastante nuevo, y hay un capítulo al final que me sorprendió. Se titula "el futuro de la integración continua" y se centra en dos preguntas interesantes:
La primera pregunta no nos preocupa internamente en Códice pero la segunda es probablemente uno de los mayores problemas que tenemos aquí en Códice ¿Se puede solucionar con un control de versiones?
El autor comienza examinando la primera pregunta: ¿se puede prevenir el que se rompa una versión?, y si es así, ¿cómo? Bueno, pues aquí dice algo que me sorprende:
Imaginemos que la única actividad que un desarrollador necesita realizar es commit de su código en el sistema de control de versiones. Antes de que el repositorio acepte el código realiza una integración en otro equipo.
Sólo se subirá el código al repositorio si la integración de la nueva versión se realiza correctamente. Esto puede reducir significativamente el problema de versiones que se rompan y puede reducir la necesidad de realizar integraciones manuales.
Entonces dibuja un gráfico que representa una "integración en cadena lineal automatizada". Incluye algo como la protección del código en dos fases, por lo que el código no llega a la línea principal hasta que hayan pasado los tests...
No se si se me olvida algo ya que creo que es una respuesta demasiado obvia, algo que todos los usuarios de Plastic se saben de memoria... proteger a una rama separada, hacer un rebase desde la rama principal, pasar las pruebas y solo integrar (copiar hacia arriba) si se pasan las pruebas...Ramificar es la respuesta, ¿no?
Quiero decir, no podía entender una configuración tan "futurista" con un escenario de commit de dos fases, si esto es precisamente es lo que ya tienes con sistemas con un buen soporte de ramas.
Entiendo que dice "la única actividad que un desarrollador tiene que hacer es commit de sus cambios", su problema no es simplemente el proteger los cambios sino el tener un lugar en el que el código pueda estar en una especie de estado intermedio y que mientres se estén realizando las pruebas el desarrollador pueda continuar trabajando.
De nuevo debo de estar perdiéndome algo aquí, ya que sólo veo un motivo de "mejora para un futuro": el autor está siempre pensando en desarrollo en la línea principal (trabajar sólo con la rama principal o como mucho unas pocas más y directamente proteger los cambios en esta rama principal). Si estás acostumbrado a patrones como el de "rama por tarea", entonces no tendrás este problema. Estarás acostumbrado a incluir tus cambios en el control de versiones y continuar trabajando en otra cosa sin corromper la línea principal.
Él continúa diciendo:
Una alternativa puede ser dar al desarrollador la capacidad de realizar una integración utilizando una máquina dedicada a integrar nuevas versiones con sus cambios locales (que no han sido aún incluidos en el repositorio del control de versiones), junto con otros que se hayan incluido en el repositorio del control de versiones.
¡Pues claro que lo es! Por esto es por lo que rama por tarea es mejor alternativa que el desarrollo a la línea principal para casi cualquier escenario de desarrollo que he visto en mi vida.
El problema detrás de estas afirmaciones tiene un nombre: los controles de versiones más conocidos (incluyendo el glorificado Subversion, que es la herramienta en la que se centra el libro) tienen enormes problemas gestionando ramas. No siempre fallan al crear un gran número de ramas (que es lo que me dicen los usuarios de SVN o CVS cuando menciono que Plastic puede gestionar miles de ramas..."mi sistema también"), el problema es gestionarlas después de unos cuantos meses (en el día de las pruebas todo funciona bien, ¿no?), hacer integraciones, comprobar lo que se ha modificado en la rama, seguir la evolución de las ramas, etc. Y, crean o no (y este es el motivo inicial de que crearamos Plastic), todas estas herramientas muy utilizadas y conocidas y a veces gratuitas, carecen de métodos adecuados de visualización, herramientas adecuadas para realizar integraciones (bueno, en algunos casos hay herramientas de terceros que se pueden integrar) y a veces incluso carecen de características básicas como seguimiento de integraciones o renombrado de ficheros.
Supongo que este es el motivo por el que después de 200 páginas de una buena lectura encuentro un capítulo tan obvio que describe como innovación del futuro algunas de las prácticas más utilizadas en SCM. Yo recomendaría ir al clásico Software Configuration Management Patterns, que aún considero el libro de SCM mejor escrito.
La pregunta de cómo agilizar las pruebas sigue sin respuesta...
0 comentarios:
Publicar un comentario