26 abril 2007
Ramas en subversion
Cuando se va a implementar una nueva caracterísitca en Unkasoft Platform, bueno, cualquier software en realidad, corres el peligro de esa nueva característica deje el software inestable o peor, sin nisiquiera compilar.
Para evitar que la inclusión de algo nuevo impida a los demás continuar su desarrollo usamos el mecanismo de ramas que aporta subversion. Básicamente el sistema se basa en hacer una "copia" del código actual y llevarlo a un presente paralelo en el que si haces cambios no afectan al código principal (también llamado trunk). Una vez se ha terminado de modificar el código en ese "universo paralelo" hay que volver a la realidad, esto es, mezclar los cambios de la rama con trunk.
Dicho esto ya se pueden enumerar varias pegas:
1.- si tardas mucho en mezclar una rama al final el mezclado con trunk es un infierno
2.- se hace difícil de gestionar y de mantener, sobretodo si no tienes "acoplado" subversion con el tracker de ramas.
En un principio planteamos usar este sistema para cualquier bug o mejora que tuvieramos que implementar, sin embargo los dos puntos anteriores nos echaron hacia atrás, dejándo solo la creación de ramas para cambios que pudiesen desestabilizar el sistema. Es lo que denominan "The Branch-When-Needed system".
El sistema usado tiene sus ventajas:
- aisla un cambio de otros, con lo cual si dejas el código a la mitad no afecta a nadie
- se pueden probar las caracterísitcas por separado con la ventaja de si salen bugs se pueden corregir sobre la misma rama sin llegar a la principal
y sus pegas:
- es un infierno hacer merge de ramas antiguas. Hemos puesto como límite de vida de una rama una semana para evitarnos males mayores.
- con los renombrados, copias y demás se hace un poco lioso (aún más) el proceso de mezcla.
- es difícil de mantener si no hay alguien que controle las ramas activas, aunque sean pocas. Durante una semana se puede olvidar actualizar el tracker y al cabo de un tiempo no sabes si mezclaste o no.
Por ahora nos vamos acostumbrando al proceso, estamos buscando el mejor sistema para que las mezclas no sean tan traumáticas y para automatizar algunos procesos como por ejemplo la creación de ramas, la numeración de las ramas para QA, etc, etc (siempre hay algo que automatizar). Menos mal que está ant de por medio, aunque muchas veces se echa de menos la potencia de python :(. La teoría es buena pero la práctica no lo es tanto.
¿y tú? ¿te vas por las ramas o prefieres tener los pies sobre trunk?
Para evitar que la inclusión de algo nuevo impida a los demás continuar su desarrollo usamos el mecanismo de ramas que aporta subversion. Básicamente el sistema se basa en hacer una "copia" del código actual y llevarlo a un presente paralelo en el que si haces cambios no afectan al código principal (también llamado trunk). Una vez se ha terminado de modificar el código en ese "universo paralelo" hay que volver a la realidad, esto es, mezclar los cambios de la rama con trunk.
Dicho esto ya se pueden enumerar varias pegas:
1.- si tardas mucho en mezclar una rama al final el mezclado con trunk es un infierno
2.- se hace difícil de gestionar y de mantener, sobretodo si no tienes "acoplado" subversion con el tracker de ramas.
En un principio planteamos usar este sistema para cualquier bug o mejora que tuvieramos que implementar, sin embargo los dos puntos anteriores nos echaron hacia atrás, dejándo solo la creación de ramas para cambios que pudiesen desestabilizar el sistema. Es lo que denominan "The Branch-When-Needed system".
El sistema usado tiene sus ventajas:
- aisla un cambio de otros, con lo cual si dejas el código a la mitad no afecta a nadie
- se pueden probar las caracterísitcas por separado con la ventaja de si salen bugs se pueden corregir sobre la misma rama sin llegar a la principal
y sus pegas:
- es un infierno hacer merge de ramas antiguas. Hemos puesto como límite de vida de una rama una semana para evitarnos males mayores.
- con los renombrados, copias y demás se hace un poco lioso (aún más) el proceso de mezcla.
- es difícil de mantener si no hay alguien que controle las ramas activas, aunque sean pocas. Durante una semana se puede olvidar actualizar el tracker y al cabo de un tiempo no sabes si mezclaste o no.
Por ahora nos vamos acostumbrando al proceso, estamos buscando el mejor sistema para que las mezclas no sean tan traumáticas y para automatizar algunos procesos como por ejemplo la creación de ramas, la numeración de las ramas para QA, etc, etc (siempre hay algo que automatizar). Menos mal que está ant de por medio, aunque muchas veces se echa de menos la potencia de python :(. La teoría es buena pero la práctica no lo es tanto.
¿y tú? ¿te vas por las ramas o prefieres tener los pies sobre trunk?
Etiquetas: agile, Unkasoft Platform
Comentarios:
dice...
Ya se que es una salvajada lo que voy a decir, pero has de mantener trunk sin generar nunca versiones especificas. A través de (directivas de precompilador+el fichero de configuración del juego+una buena estructura de montaje+ant+experiencia) puedes mantener un solo código.
Todo esto lo digo, porque nunca se saben las cosas que se le puede ocurrir al comercial de turno, al fin y al cabo, el último mono es el programador, y con esta estructura y un poco de paranoia he conseguido controlar esas peticiones aleatorias dentro de lo lógico.
Javi Santana dice...
No tengo ni idea de cómo puedes llevar algo así, podrías explicar un poco más como lo haces?
Lo bueno de este sistema es que solo hay un código para la release que no interfiere con el resto. Que viene el comercial dándote la chapa ya verás tú donde implementas o cambias el sistema. O incluso si haces un hack bestial puedes hacer una rama y no joder todo el código por el típico cambio de última hora.
dice...
Trataré de dar una explicación corta.
El precompilador te permite utilizar distintas librerias en un mismo código.
El fichero de configuracion del juego es el aspecto mas critico. Has de alcanzar el grado supremo de paranoia y programar siempre teniendo en cuenta todos los peligros, desde los comerciales locos, hasta móbiles sin memoria y de lentitud suprema. Mi manera de hacer las cosas es desarrollar en paralelo todas las versiones, desde la mas potente a la mas mierda.
Una buena estructura de montaje+ant te permite generar nuevas versiones de manera flexible y rapida solo añadiendo una nueva configuración y nuevos recursos.
Finalmente la experiencia te permite con el tiempo poder preveer los problemas y tratar de adelantarte a ellos.
Con este manera de hacer al menos he conseguido decrementar el número de fines de semanas que me ha tocado pringar trabajando. Eso si, de lunes a viernes, toca trabajar duro mientras otros se pueden estar rascando los mismisimos, pero creo que compensa ya que el número de amenazas en malas epocas decrece y la vida del programador deja de ser una puñetera montaña rusa, para convertirse en una subida durilla pero constante.
Juan Antonio Muñoz-Gallego dice...
Dios mio, eso es el nivel CMM 1, nivel heroico con monumento al desarrollador. Espero que al menos te lo agradezcan
Publicar un comentario
<< Home
dice...Ya se que es una salvajada lo que voy a decir, pero has de mantener trunk sin generar nunca versiones especificas. A través de (directivas de precompilador+el fichero de configuración del juego+una buena estructura de montaje+ant+experiencia) puedes mantener un solo código.
Todo esto lo digo, porque nunca se saben las cosas que se le puede ocurrir al comercial de turno, al fin y al cabo, el último mono es el programador, y con esta estructura y un poco de paranoia he conseguido controlar esas peticiones aleatorias dentro de lo lógico.
Javi Santana dice...No tengo ni idea de cómo puedes llevar algo así, podrías explicar un poco más como lo haces?
Lo bueno de este sistema es que solo hay un código para la release que no interfiere con el resto. Que viene el comercial dándote la chapa ya verás tú donde implementas o cambias el sistema. O incluso si haces un hack bestial puedes hacer una rama y no joder todo el código por el típico cambio de última hora.
dice...Trataré de dar una explicación corta.
El precompilador te permite utilizar distintas librerias en un mismo código.
El fichero de configuracion del juego es el aspecto mas critico. Has de alcanzar el grado supremo de paranoia y programar siempre teniendo en cuenta todos los peligros, desde los comerciales locos, hasta móbiles sin memoria y de lentitud suprema. Mi manera de hacer las cosas es desarrollar en paralelo todas las versiones, desde la mas potente a la mas mierda.
Una buena estructura de montaje+ant te permite generar nuevas versiones de manera flexible y rapida solo añadiendo una nueva configuración y nuevos recursos.
Finalmente la experiencia te permite con el tiempo poder preveer los problemas y tratar de adelantarte a ellos.
Con este manera de hacer al menos he conseguido decrementar el número de fines de semanas que me ha tocado pringar trabajando. Eso si, de lunes a viernes, toca trabajar duro mientras otros se pueden estar rascando los mismisimos, pero creo que compensa ya que el número de amenazas en malas epocas decrece y la vida del programador deja de ser una puñetera montaña rusa, para convertirse en una subida durilla pero constante.
Juan Antonio Muñoz-Gallego dice...Dios mio, eso es el nivel CMM 1, nivel heroico con monumento al desarrollador. Espero que al menos te lo agradezcan
Publicar un comentario
<< Home
