Control de versiones

Introducción

Tengo que decirte una cosa antes de que empieces a leer… ¡tenía ganas de escribir este artículo! Seguro que te preguntas el por qué… pues tenía ganas porque es un punto muy importante a tener en cuenta cuando desarrollas código fuente, ya que te permite tener el control sobre el código que desarrollas, aspecto fundamental para el éxito del proyecto.

Estoy seguro que cuando empiezas un proyecto nuevo de desarrollo de software te centras primero en diseñar la arquitectura de la solución que quieres implementar, posteriormente vas bajando el nivel de abstracción hasta finalmente llegar al diseño más bajo de la misma. Y ahora es cuando viene mi pregunta: ¿Cuándo diseñas el modo de trabajar con el código fuente que vas a utilizar?

El objetivo que tengo para ti con este artículo es que comprendas la importancia de utilizar un sistema de control de versiones para el código fuente y que conozcas las dos formas más utilizadas que existen de trabajar con el código fuente.

¡Empecemos!

Glosario

Antes de empezar con el artículo voy a ponerte un pequeño listado de términos que voy a utilizar y que debes de conocer siempre que hables de sistemas de control de versiones:

Sistema de control de versiones: Software que permite realizar la trazabilidad sobre los cambios que se realizan en el código fuente. Permite recuperar versiones anteriores del código fuente, lo que hace que sea más fácil de mantener el código y de trabajar con él.
Branch: Un branch o rama de código fuente es un duplicado del código fuente sobre el que se va a trabajar.
Trunk: Rama principal de código fuente.
Merge: Operación de fusión de diferentes ramas.
Commit: Operación de confirmación de cambios en el sistema de control de versiones.
Changeset: Conjunto de cambios que hace un usuario y sobre los que se realiza una operación «Commit» de manera simultánea y que son identificados mediante un número único en el sistema de control de versiones.

Evolución

Los sistemas de control de versiones de código fuente han ido evolucionando a lo largo de la historia.

En un primero momento se hacían copias manuales por parte de los desarrolladores, antes de introducir cambios en el código fuente hacían copias de seguridad del proyecto por su tuvieran que deshacer los nuevos cambios que se iban a hacer.

Este proceso generó la necesidad de automatizar el proceso, y es por ello por lo que aparecieron los sistemas de control de versiones del código fuente:

Primera generación: Permitían el trabajo concurrente mediante bloqueo de ficheros, lo que provocaba que únicamente una persona pudiera trabajar a la vez con un fichero. Por cada usuario, únicamente permitían trabajar con un único fichero.
Segunda generación: Aumentarón la capacidad de trabajar simultáneamente sobre los ficheros, los usuarios debían de realizar la operación «Merge» antes de realizar la operación «Commit». La gestión estaba centralizada y se permitía trabajar con varios ficheros a la vez.
Tercera generación: Son los sistemas actuales que todos usamos, eliminan la restricción de los de segunda generación relacionada con tener que realizar la operación «Merge» antes de la operación «Commit», es decir, permiten realizar ambas operaciones por separado y de forma independiente. Introducen el concepto de «Changeset» y la gestión se realiza de forma distribuida, es decir, no está centralizada en un único punto como los de segunda generación.

Git

En estos momentos, el sistema de controls de versiones que más está siendo utilizado es Git (https://git-scm.com), con una cuota de mercado del 70% más o menos.

La historia de Git es fácil y se puede resumir en pocas palabras: Git fue desarrollado después de que el sistema de control de versiones que se utilizaba para el núcleo de Linux pasara a ser de pago, en ese momento, el proyecto Git, liderado por Linus Torvalds (creador de Linux), comenzó su andadura y en 2005 empezó a ser utilizado.

En este artículo no voy a hablarte de todo lo que puede ofrecerte Git, voy a centrarme en que conozcas las dos formas de desarrollar más populares que puedes utilizar con Git.

Git flow

La primera forma de trabajar con el código fuente que te voy a presentar se llama Git Flow.

La característia principal es que el código fuente principal se encuentra en una rama llamada «Develop», con un acceso bastante estricto. La forma de trabajar es sencillo, los desarrolladores crean ramas tomando la rama «Develop» como base, estas ramas son llamadas «Feature».

La característica principal es que antes de hacer una operación merge de la rama «Feature» con la rama «Develop» se abre una discusión entre todos los desarrolladores para aceptar todos los cambios en la rama «Develop».

El código fuente de la rama «Develop» que va a ser definitivo de la versión sobre la que se trabaja será separado en una rama llamada «Release». La versión del código fuente final almacenada en la rama «Release» es probado, además, los bugs que contenga son corregidos sobre la propia rama «Release». Al código fuente de la versión definitiva de la rama «Release» se le hace una operación de merge con la rama «Master», que es la rama que contiene las versiones liberadas.

A continuación te pongo un ejemplo de Git Flow:

Supongo que la pregunta que te estás haciendo es… ¿Cuándo debo de usar este tipo de control de código fuente? Te pongo unos ejemplos:

El equipo de desarrollo está compuesto por muchos miembros junior.
El proyecto sobre el que se trabaja es Open Source.
Productos en producción.

Trunk based development

La segunda forma que de trabajar con el código fuente que te voy a presentar se llama Trunk based development.

Es una forma de trabajo muy sencilla, todos los desarrolladores trabajan sobre una única rama de código, conocida como «Master», y suben los cambios que realizan a dicha rama.

A las versiones finales de código fuente se les crea una rama específica para dicha versión. Todas las ramas de versiones son conocidas como ramas «Release».

A continuación te pongo un ejemplo de Trunk based development:

¿Cuándo debes de utilizar este tipo de control de código fuente?

Necesidades de desarrollo y liberación rápido.
El equipo de desarrollo está compuesto por miembros senior.
Cuando estás empezando un proyecto, ya que facilita el desarrollo inicial rápido.

Conclusiones

En este artículo te he presentado la necesidad de utilizar un control de versiones en todos los desarrollos, también te he introducido a los dos modos de trabajo más comunes que se utilizan.

El control de versiones es de vital importancia en desarrollo de software, aunque existe una cantidad muy grande de literatura al respecto e internet, con el artículo he pretendido introducirte en este mundo y que tengas las nociones básicas para empezar a utilizarlos.

Lo más importante es probar y probar, por lo que… ¡a qué esperas! ¡Empieza por Git! https://git-scm.com