Too Cool for Internet Explorer

Buenas prácticas utilizando control de versiones

Hora y Fecha: Enero 7, 2007 @ 3:23 am Autor: Moisés Maciá
Categorías:
1,247 views

Sistemas de control de versiones hay muchos y muy variados: CVS, Subversion, Darcs, StarTeam, etc. Son herramientas muy valiosas, tanto que ningún programador puede omitirlas. En la siguiente nota voy a comentar algunos hábitos que he observado en la gente que las utiliza:

No utilices el control de versiones como si fuera un backup

Este es uno de los mayores errores a la hora de utilizar estas herramientas. Frecuentemente oigo la frase: ¿has puesto a salvo tu código en el repositorio?. ¡Mal! Almacenar el código en un repositorio no es sinónimo de seguridad, la seguridad la proporciona una copia de respaldo de ese código, no el repositorio en sí.

Tomaremos como ejemplo Darcs, un sistema de control de versiones no muy conocido. Este soft funciona en local, como un proceso más, sin necesidad de centralizar el control en un servidor como ocurre con otros sistemas como CVS o Subversion. En este caso, un fallo de disco podría echar a perder tu trabajo; por esta razón debes hacer copias de seguridad, el sistema de control de versiones no tiene nada que hacer ante este tipo de contingentes.

Los desarrolladores que utilizan el control de versiones con el rol de sistema de backup frecuentemente hacen un commit de su trabajo al día, por ejemplo cuando termina su jornada laboral, como una forma de respaldo diario. Esta no es una práctica aceptable, especialmente si formas parte de un equipo de desarrollo. Imagina que sólo actualizas tu proyecto por la mañana, cuando empieza tu jornada, y remites los cambios al finalizarla. Cada mañana perderás mucho tiempo únicamente lidiando con todos los cambios que enviaron tus compañeros el día anterior y que entran en conflicto con los que tu hiciste. No es una práctica muy inteligente, ¿no crees?

Remite los cambios tan pronto como conformen una unidad lógica

¿Cada cuanto debo remitir los cambios?. Hay que llegar a un término medio: no remitas cada línea que escribes ni lo hagas después de todo el día trabajando. Debes hacer un commit tan pronto como los cambios conformen una unidad lógica, por ejemplo cada vez que un conjunto de cambios tengan sentido.

Estas unidades lógicas responden en la mayoría de los casos a tu plan de desarrollo: encuentras un bug en la rama de desarrollo actual, planeas una estrategia para solucionarlo, lo arreglas y ahí tienes tu unidad lógica: envía los cambios al repositorio. El commit cobra sentido porque soluciona un bug específico; la versión X tiene un bug y la versión X+1 ya no.

No tengas miedo de remitir pequeños cambios con mucha frecuencia, nadie se enfadará porque seas conciso solucionando cosas pequeñas. Considera la situación extrema en la que, después de meses de desarrollo, necesitas recordar cual fue la revisión en la que se solucionó aquella falta de ortografía en una cadena de depuración. Si utilizaste correctamente el patrón de “una solución, un envío” no tienes más que investigar la lista de envíos para descubrir cual de ellos estas buscando.

Frecuentemente ocurre que estas trabajando en una “unidad lógica” cuando descubres que hay un error en otra parte del código y lo corriges, y envías la corrección junto con tus cambios todo dentro de un mismo commit haciendo que esta corrección pierda visibilidad. Esto debe evitarse en la medida de lo posible.

Se preciso y exhaustivo en los comentarios

Una de las cosas que más me enerva son los commit en blanco. Cada envío al repositorio debe ir asociado obligatoriamente con un comentario que explique lo que se hizo. Si trabajas en un equipo de desarrollo, tus compañeros se verán frustrados y te desearán una muerte dolorosa cada vez que actualicen el proyecto y se encuentren con docenas de cambios “en blanco” ¿Qué demonios hizo este tio? Si trabajas solo, tarde o temprano te encontrarás buceando entre una interminable lista de cambios en blanco y te desearás una dolorosa muerte por no haber documentado apropiadamente tu propio trabajo.

Por favor sé preciso y explica con detalle cada una de las cosas que haces. En el caso óptimo podrás localizar lo que buscas tan solo mirando la lista de cambios.

Nunca rompas trunk

Si remites cambios en blanco desearé tu muerte, pero si rompes la rama principal !pondré medios para asegurarme que mueras!. Romper la rama principal de desarrollo es la manera más simple y directa de joder a todo el equipo de desarrollo desde la comodidad de tu cubículo.

Si alguien envía un parche que rompe la rama y yo actualizo, automáticamente mi copia de proyecto se rompe y me quedo sin poder trabajar hasta que la persona que remitió el parche no lo solucione. La idea es: verifica siempre tus cambios antes de enviarlos al repositorio.

Otra cosa muy habitual es realizar varios cambios, crear nuevos ficheros, comprobar que todo funciona bien antes de enviar, pero olvidar ¡incluir los nuevos archivos bajo el control de versiones!

Mandamiento donut

Y el señor dijo a los hombres:
“Aquel que actualice el repositorio rompiendo la compilación deberá pagar una penitencia en donuts”
Esa es la ley.





« Anterior post: Primera technical preview de CakePHP 1.2 | Próximo post: Mac World Expo 2007 »

10 Comentarios para “Buenas prácticas utilizando control de versiones”

Cheli
7 de Enero de 2007 a las 8:32 am    

Como de costumbre fantástico.

Una pregunta, cuando te refieres a copias de seguridad del código, ¿te refieres a la última versión o a todo el repositorio con sus correspondientes históricos de cambios?

Cheli

Moisés Maciá
7 de Enero de 2007 a las 2:14 pm    

En Subversion puedes hacer tres cosas:

  1. Hacer un backup de la última versión del código con svn checkout, lo cual no sirve de mucho ya que pierrdes todo el historial de cambios.
  2. Hacer un backup del directorio del repositorio tal cual.
  3. O la opción recomendada, hacer un volcado con svnadmin dump

El volcado lo puedes convertir de nuevo en un repositorio o guardar una copia.

maeghith
7 de Enero de 2007 a las 4:05 pm    

hmmm… no se, lo de “¿has puesto a salvo tu código?” yo lo entiendo como “si debes hacer el commit no te olvides de hacerlo” que equivaldría a salvar el código (más o menos), aunque sabiendo como es la gente no me extrañaría nada encontrar que hay gente que hace como dices.

Estupendo artículo, me lo guardo, gracias :)

programame.net
7 de Enero de 2007 a las 6:31 pm    

Buenas prácticas utilizando control de versiones…

Sistemas de control de versiones hay muchos y muy variados: CVS, Subversion, Darcs, StarTeam, etc. Son herramientas muy valiosas, tanto que ningún programador puede omitirlas. En la siguiente nota voy a comentar algunos hábitos que he observado en la…

meneame.net
7 de Enero de 2007 a las 8:50 pm    

Buenas prácticas utilizando control de versiones…

Excelente manual y consejos para aprender a usar control de versiones. "No utilices el control de versiones como si fuera un backup", "Remite los cambios tan pronto como conformen una unidad lógica", "Se preciso y exhaustivo …

alexander gomez
22 de Marzo de 2007 a las 10:35 pm    

estoy interesado en crear un sistema controlador de versiones si alguien me puede colaborar guiandome o ayudandome de alguna forma se lo agradeseria.

Moisés Maciá
22 de Marzo de 2007 a las 11:28 pm    

Lo mejor que puedes hacer es leerte la documentación de Subversion, cualquier duda seguro que esta respondida.

[...] los interesados en conocer más sobre los sistemas de control de versiones: Quarkblog [...]

Alexei Eleusis Díaz Vera
19 de Agosto de 2007 a las 6:43 pm    

Saludos, he leído varias entradas de tu blog y me parece muy bueno, muchas felicidades.

Respecto a la (prácticamente inveitable) penitencia de las donas. Creo que una buena práctica es tener un servidor de integración continua o un mecanismo similar que permita conocer a todo el equipo el estado del código antes de hacer una actualización. De hecho si no existe una herramienta de integración contínua que se adecue a tus necesidades, puedes incluso utilizar uno de los hooks de subversion para tal efecto. Y para un respaldo automático agregar una tarea a cron que respalde el repositorio completo.

OBTrainings » Blog Archive » ¿Cómo desarrollar?
21 de Septiembre de 2008 a las 5:34 pm    

[...] de Software Libre de Alicante) escribió un artículo que me gustó mucho sobre el tema os dejo el enlace y os lo [...]


Bad Behavior has blocked 371 access attempts in the last 7 days.