Control de Versiones: Etiquedas y Ramas

Las ramas y las etiquetas pueden tener muchos usos y por eso se puede hacer complicado su uso.

Las etiquetas se usan para marcar el proyecto cuando está en un determinado estado.
Las ramas representan una bifurcación en la historia del proyecto.

Deberíamos usar una rama cuando lanzamos una versión del producto o por ejemplo cuando vamos a implementar funciones experimentales. Cada release brach puede tener varias releases o puntos donde la aplicación fue puesta a disposición del cliente. Estos puntos de marcan con las etiquetas.

Los bugs se fijan en la release branch correspondiente y el cambio se fusiona en las restantes ramas. Si el bug es complicado se puede crear una rama y luego fusionarla con las restantes ramas. Nota: El programa SourceOfSite no dispone de opciones para fusionar ramas.
Se usan etiquetas para marcar el comienzo y el final del bugfixing.

Para decidir si necesitamos una rama tenemos que pensar que esa rama deberá ser mantenida, es decir, que habrá que modificar algún fichero y fusionarla con las otras ramas en un futuro. Si no se va a mantener una rama es mejor usar una etiqueta. Tampoco es buena idea crear una rama para una modificación especifica de la aplicación para un determinado cliente. Esto habría que hacerlo la propia aplicación.

Control de Versiones

¿Qué es?
Es un software que facilita el trabajo de un programador.

• Se podría considerar como el deshacer de un editor de textos pero para el código fuente.

• Permite a múltiples programadores trabajar sobre el mismo código de manera controlada.

• Mantiene un registro de los cambios realizados.

• Permite llevar múltiples versiones del código mientras se continua trabajando sobre dicho código.

¿Qué se debería guardar?
Para saber que debemos guardar en el repositorio haz la siguiente pregunta: ¿Si no tengo una versión actualizada de x, ¿podría compilar, probar y distribuir la aplicación? Si la respuesta es no, entonces x debe guardarse en el repositorio.

Además de los ficheros anteriores, también se debe guardar cualquier cosa que ayude a entender la aplicación, ya sea documentación interna o externa, el texto de los correos electrónicos que hayan sido importantes en el desarrollo de la aplicación, información,....

No se deben guardar los ficheros que se pueden generar con ficheros ya existentes, por ejemplo: la documentación que generamos mediante la documentación incluida en el código fuente usando herramientas auxiliares.

Tags - Etiquetas
Es un nombre que se asigna a un conjunto de ficheros en un estado determinado del proyecto. De este modo podemos recuperar esos ficheros tal y como estaban en ese momento.

Branches - Ramas.
Se llama Trunk a la rama principal del código donde se trabaja normalmente. Es decir, los ficheros del repositorio donde hacemos los cambios diariamente.
Pero, si estamos próximos al lanzamiento de la aplicación, no podemos añadir más funcionalidad pues esa funcionalidad será para una futura versión, y seguramente no estará termianda para el lanzamiento de la aplicación. Entonces, lo que podemos hacer es crear una rama que contendrá el código fuente para una determinada versión de la aplicación. Es lo que se conoce como release branch.

Cuando creamos una rama tenemos 2 proyectos con un futuro distinto para cada uno de ellos. De esta manera tenemos el código de la aplicación que vamos a lanzar y el de la futura versión perfectamente diferenciados.
Si después del lanzamiento de la aplicación se encuentran fallos se corregirán en la rama correspondiente, así podemos generar la misma versión con los fallos corregidos, y esos cambios para reparar el bugs en la release branch se fusionan con la rama principal o trunk branch.

En general, un proyecto tendrá una rama principal (trunk), y por cada lanzamiento podemos añadir otra rama (release branch). Una release branch no cambia mucho durante su vida, sólo para corregir los fallos que se puedan encontrar.

Los cambios significativos en la vida de un proyecto se marcan amenudo con etiquetas. Una etiqueta podría contener el código usado para lanzar una determinada versión de la aplicación.

Merging - Fusionando.
Esos cambios se deben añadir también a la rama principal para que estén corregidos en la próxima versión.
Se pueden fusionar los cambios hechos para fijar el error en la rama correspondiente con la rama de la siguiente versión sin usar el copiar y pegar.
Mantener el código entre las distintas ramas puede ser complicado, por eso es recomendable no tener muchas ramas.

Logs
Cuando un fichero es modificado y puesto en el repositorio se puede añadir una nota. En esa nota no se explica el cambio realizado, ya que este se puede obtener al ver las diferencias entre los ficheros. Lo que debemos poner en el log es el por que se ha realizado el cambio. Si el cambio es para fijar un bug se debe poner la identidad del bug en la aplicación que usemos para llevar el control de errores.

Tip 11: DRY—Don't Repeat Yourself - No te repitas

Un programador reune, organiza, mantiene y utiliza conocimientos. Se documentan en las especificaciones, cobran vida al ejecutar el código y se usan durante los test al comprobar los resultados.
Estos conocimientos no son estables y cambian durante el desarrollo de la aplicación.

Una buena costumbre es no duplicar el conocimiento. Debe ser expresado en un sólo lugar, así, si este conocimiento cambia, sólo habrá que modificarlo en dicho lugar.

La mayoría de las duplicaciones se pueden encontrar dentro de las siguientes categorías:

• Duplicación impuesta. Parece que no hay elección, el sistema parece que requiere de duplicación. Con un poco ingenio puede que se evite la duplicación. Al documentar el código se está duplicando información, para evitarla, el propio código debe ser la documentación de bajo nivel, mientras que los comentarios sería la explicación de de alto nivel.
  
• Duplicación inadvertida. A veces se está duplicando la información por errores en el diseño. Por ejemplo, una linea esta compuesta por 2 puntos o por un punto y un ángulo y una distancia. Una clase que define la linea tiene información duplicada si tiene 2 puntos y una longitud.
  
• Duplicación impaciente. Se duplica porque parece más fácil copiar y pegar y modificar un poco. En ese momento puede resultar beneficioso, pero a la larga requerirá más tiempo.
  
• Duplicación multiprogramador.Varios programadores duplican información. Para evitarlo lo mejor es una buena comunicación entre programadores.
  

Tip 10: It's Both What You Say and the Way You Say It - Es tanto lo que se dice como la manera en que se dice.

Un programador se comunica de muchas formas diferentes, en el grupo de trabajo, con el usuario final, con el ordenador,... por lo tanto debe hacerlo bien. Algunas ideas para llevarlo a cabo son:

Saber lo que se quiere comunicar. Hay que planear lo que se quiere comunicar y refinarlo para comunicar lo que realmente queremos.

Conocer a la audiencia. Para eso algunas preguntas que podemos hacernos son:
¿Qué quieres que aprendan?
¿Qué interés tienen en lo que pretendes comunicar?
¿Cuantos detalles quieren?
¿Cómo pueden motivarse para que escuchen?

Elegir el momento. La última hora de un viernes generalmente es un mal momento para realizar cualquier comunicación. También se pueden presentar ocaciones en las que una propuesta sea aceptada por algún acontecimiento que haya sucedido.

Elegir el estilo. En algunos casos puede valer con unas lineas, un correo. En otros se puede necesitar un documento detallado. Si hay dudas, lo mejor es preguntar.

Hay que hacerlo bonito. No sólo el contenido es importante, el formato, el tipo de letra, las faltas de ortografía,...

Implicar a los destinatarios para que nos comenten que les parece el documento.

Escuchar. Si escuchamos seremos escuchados. Hay que animar a hacer preguntas para hacer de la presentación un dialogo.

Siempre responder en el momento, aunque la respuesta sea que lo vas a mirar. Hay que mantener a las personas informadas para que no sientan que nos hemos olvidado del asunto.

Tip 9: Critically Analyze What You Read and Hear - Analiza criticamente lo que leas y oigas

No hay que creer todo lo que se lee, hay que analizarlo.
No sabemos los intereses que puede haber detrás de ese artículo que estamos leyendo.

Tip 8: Invest Regularly in Your Knowledge Portfolio - Ampliar conocimientos regularmente.

El Knownledge Porfolio de un programador es como una cartera de inversiones y por lo tanto hay que:

- Invertir regularmente: Aunque sea una pequeña cantidad, la suma es lo importante.
- Diversificar: Cuantos más conocimientos diferentes se tengan mas valor tiene el programador.
- Administrar el riesgo: No hay que especializarse demasiado en una tecnología.
- Compra barato, vende caro: Aprender alguna tecnología que está empezando puede ser duro, pero la ventaja de ser de los primeros en usarla puede tener grandes recompensas.
- Revisa y reequilibra: Esta es una industria muy dinámica, lo que hoy es última tecnología mañana puede estar anticuada.

Los consejos que nos dan para conseguirlo son:

- Aprender al menos un lenguaje cada año.
- Leer un libro técnico cada trimestre.
- Leer libros no técnicos también, porque no hay que olvidar que los ordenadores los usan personas.
- Asistir a clases.
- Participar en grupos locales.
- Experimentar con distintos entornos, si en el trabajo usas Windows en casa usa Linux por ejemplo.
- Estar actualizado, subscribiendose a listas de noticias sobre tecnología,...
- Conéctate, navega por Internet para encontrar información que te puede ser útil.

Todo esto necesita tiempo, y no se dispone de mucho, por lo que hay que tener preparado algo para leer en los tiempos muertos.