4 reglas para tu proceso de control de versiones
Al principio todo era plano.
Pero ahora, ¡afortunadamente!, ya no es así...
Antecedentes
Vale, ¿por qué estoy escribiendo esto? Esta semana tuve la oportunidad de ver dos estupendas presentaciones de OSCON 2008:
La primera es de Mark Shuttleworth (Canonical, Ubuntu), titulada Más allá del desarrollo ágil: Posibilitar la Siguiente Generación de Métodos de Desarrollo de Software, y que trata sobre diversos temas muy interesantes tales como Lean Software Development. Podéis ver una presentación aqui, merece la pena.
La que realmente me gustó fué la diapositiva 17 en la que dice:
Branching and Merging
Keep trunk pristine,
Keep features flowing,
Release on demand.
Que yo traduzco por:
Ramificación e integración
Mantener la línea principal impoluta,
Mantener la potencia de la herramienta en uso,
Crear versiones bajo demanda.
Y la diapositiva 20 dónde menciona:
Pre-Commit Testing
I see you knocking
but you can't come in.
Que viene a ser:
Probar antes de realizar commit
Veo que estás llamando
pero no puedes entrar.
Como veis se centran en un punto crítico que es pasar todo el juego de tests antes de hacer commit, algo que puede sonar opuesto a la integración continua, pero que en realidad es una evolución del modelo.
También me gustó Code Reviews for Fun and Profit de Alex Martelli (Google) que se puede encontrar aquí .
Menciona lo siguiente en la diapositiva 26:
idealmente, la CR (code review) debería de tener lugar ANTES
del commit/inclusión de cambios en la
base de código
-- mantener la línea principal/inteligente/consejo de calidad
Esto también parece interesante, ¿no?
E incide sobre el mismo tema: revisar, probar, comprobar que no se rompe nada antes de hacer commit a la línea principal.
Y de todo esto se me ocurrió este post (que primero publiqué en inglés)
Las reglas
Vale, vamos a intentar localizar las principales reglas para conseguir el mejor control de versiones posible en la era post-agile:
Regla 1: Mantener la rama principal incorrupta. ¡La rama principal es tu proyecto! No la uses como un trastero (lleno de cosas que no sirven) para dejar todos los cambios y nuevas características. ¡Utiliza las ramas para eso! (Ya, ya lo oigo: "acabaremos con miles de ramas!!", claaaro, ¡y eso no es un problema! Usa un control de versiones adecuado! :-P)
Regla 2: Aislar cambios en ramas. Es una consequencia de la Regla #1. Guarda cada cambio o característica nueva en su propia rama. Ayudará a mantener la rama principal limpia, y te dará toda la potencia del desarrollo paralelo real. También es muy bueno para cambiar de tarea y hacer un seguimiento de los cambios intermedios.
Nota: Asocia tu rama con una con una tarea en tu herramienta de control de tareas (Bugzilla, Mantis, Jira ...) para poder tener el ciclo completo.
Regla 3: Guarda los cambios con cierta frecuencia, con más de la que lo haces ahora. Si desarrollas en la línea principal no harás commt cada 5 minutos, los cambios suelen tardar más en realizarse. Si tienes tu propia rama para la tarea puedes hacer commit tantas veces como quieras (¡aunque no compile!)... y luego tendrás un historial privado de los cambios.
Regla 4: Revisar los cambios antes de incluirlos en la línea principal. En el desarrollo en la rama principal (y en integración continua) se realizan las pruebas de tests después de que se hayan integrado los cambios. ¡No lo hagas! Sería demasiado tarde, el código ya está roto. Saca el máximo partido a tu herramienta de SCM, revisa los cambios antes de integrarlos.
La buena noticia es que hay herramientas que soportan este modelo, tanto en el ámbito comercial como en herramientas de código libre: plastic, accurev, git (bazaar?)...
La mala noticia es que algunas de las herramientas más utilizadas no soportan este modelo.
Llega una nueva era... ¡preparate!
0 comentarios:
Publicar un comentario