Linus habla sobre ramas...
Hace unos meses Linus Torvalds escribía sobre algunos problemas que tenían en el desarrollo del Kernel con Git debido al uso de ciertos patrones de merge.Como aprender de Linus es siempre interesante :P me gustaría entrar en detalle en los puntos que menciona y ver cómo aplicarlo para mejorar en desarrollos del día a día (no hace falta ser un kernel-hacker para sacar partido de esas técnicas). De hecho encaja con el patrón que nosotros recomendamos con Plastic aunque lógicamente él lo aplica a Git y sería también válido con cualquier otro SCM con buen soporte de ramas.
Las palabras de Linus
Esto es lo que escribió Linus, sólo he sacado un fragmento así que para tener la visión completa lo mejor es leer el link original.
The real problem is that maintainers often pick random - and not at all stable - points for their development to begin with. They just pick some random "this is where Linus -git tree is today", and do their development on top of that. THAT is the problem - they are unaware that there's some nasty bug in that version.
Y ahora intentaré traducir lo mejor posible:
El verdadero problema es que los “maintainers” a menudo cogen puntos aleatorios – y para nada estables – como partida de sus desarrollos. Simplemente cogen un “aquí es donde está el árbol de Git de Linus hoy” y hacen sus cambios sobre eso. Y ESE es el problema – no son conscientes de que hay un fallo muy feo en esa versión.
Disparando a un objetivo móvil
¿De qué está hablando Torvalds? Realmente de un problema muy bien conocido cuando se trabaja en “trunk o mainline” (vamos, sin ramas) como describía aquí hace ya algún tiempo en la sección titulada “don’t shoot a moving target!” (no dispares a un objetivo móvil).
El problema afecta duramente a todos los seguidores de la doctrina “mainline/trunk” (ya sabéis, SVN, CVS, VSS…) ya que se están actualizando constantemente a “lo más nuevo” quizá por miedo a hacer merges. Algunos intentarán solucionarlo con integración continua (CI) pero simplemente retrasarán el problema. Lo “malo” es que también afectará a quienes usen “ramas de característica” (feature branches) a menos que sigan todas las reglas (lo que nosotros solemos definir en el patrón de “rama por tarea”).
El problema con el que se encuentran en el desarrollo del kernel se ve en esta imagen:
El equipo del kernel usa ramas y todo pero ¿qué pasa si usan “master” como rama de integración (muy común, y correcto) y crean ramas desde “commits” que no están etiquetados (tagged)? (Como muestra el dibujo).
El problema es que al usarse la rama principal como punto de integración habrá “commits” intermedios (changesets) que no serán estables (especialmente si se usan los “fast-forward” merges de Git, que no me gustan un pelo, pero que supongo que no serán el problema de Torvalds ya que seguro que sabe usar Git muy bien, ¿no???). Entonces los programadores empiezan desde un punto inestable y… comienza la fiesta.
La clave son las líneas base
Nosotros hemos tenido exactamente el mismo problema con equipos usando Plastic pero que no entendieron bien al principio la importancia de tener líneas base (baselines, releases estables o como queráis llamarlas). Una vez que el código es estable: ¡etiquetadlo! Y cread las ramas de tarea SÓLO desde puntos estables!
Esa es la regla básica: cread líneas base con frecuencia (mínimo una a la semana en equipos de menos de 10 personas y más si el equipo crece) que por supuesto deben estar totalmente probadas (juego de test automático y cualquier tipo de prueba accesoria o manual que hagáis, de hecho esta es la parte larga de hacer integraciones, los merges, hoy por hoy, tienen que ser muy rápidos) y CREAD LAS RAMAS SÓLO DESDE BASELINES ESTABLES como muestra la siguiente figura:
De esta forma si algo falla en tu rama de tarea (o feature branch) sabes que… ¡es por tu culpa!, porque todos los tests estaban bien en la línea base (no sólo el juego rápido que puedes pasar en CI, también los que tardan horas).
Una regla muy, muy sencilla y con enorme ahorro en tiempo y dolores de cabeza!
0 comentarios:
Publicar un comentario