Workflow con tenientes y dictador

Herramientas para el control de versiones en el desarrollo software.

Un producto software se modifica infinitas veces durante su tiempo de vida y por lo tanto se necesita una herramienta que permita llevar un control de los distintos cambios que pueda sufrir a lo largo de su desarrollo o vida útil.

gitGIT es un SCV gratuito y de código abierto.
Se puede utilizar para proyectos pequeños y grandes.
Es fácil de aprender y tiene un buen rendimiento.

En la mayoría de productos software, muchas personas intervienen en su desarrollo y por lo tanto imprescindible que el control de versiones no se haga de forma manual puesto que se pueden cometer muchos errores y el coste sería muy alto.

¿Cómo se almacenan las distintas versiones?

Los sistemas de control de versiones se pueden clasificar según cómo se almacena el código. Tenemos dos tipos de sistemas.

Sistemas Centralizados. Su gestión es mucho más sencilla como se puede deducir. El repositorio es único y en él se almacenará todo el código del software a guardar. Generalmente en muchos software se generan varias ramas y en ese caso, un responsable deberá aprobar el almacenamiento de las distintas ramas de software. En estos sistemas el control es mayor y generalmente existe un único número de versión lo que hace que su gestión sea más sencilla. Esa rigidez implica que muchas veces se desee tener algo más de flexibilidad y por tanto optar a otro tipo de configuración como los sistemas distribuidos.

Sistemas Distribuidos. En este tipo de sistemas, cada programador mantiene una copia del repositorio. Todos los usuarios tienen una copia del software. La ventaja es que en caso de fallo habrá muchas copias de las cuales se podrá recuperar la última versión. En el servidor principal residirá la copia principal.

Cuando se quiere trabajar con versiones inestables o versiones no oficiales, muchos desarrolladores y empresas de software optan por utilizar este tipo de sistemas. En el caso que una versión inestable o de prueba supere las pruebas pertinentes, el responsable las subirá al repositorio común y formará parte del proyecto.

Generalmente este tipo de versiones se realizan cuando se quieren mejorar ciertos módulos o se quieren incorporar nuevas funcionalidades al software. Además, la ventaja de que el usuario tenga una copia del proyecto en su propio equipo hace que el trabajo sea mucho más ágil. El servidor también está más descargado y no se necesitará una máquina tan potente.

Tipos de colaboración en un sistema de control de versiones

Generalmente se colabora de dos formas en un sistema de control de versiones (SCV). La primera y más sencilla es trabajar con el sistema en exclusiva. Muchas veces un usuario es responsable de una parte o módulo de un sistema o desarrollo software. Cuando lo está modificando notifica al repositorio que esa parte esta pendiente de modificación y el mismo repositorio bloquea esa parte para que no sea modificada. Cuando finaliza el trabajo lo comunica al repositorio y sube el software modificado. El repositorio desbloquea esa parte y queda disponible para los demás usuarios.

La otra forma que hay de trabajar en un SCV es trabajar de forma colaborativa. En este caso, cada usuario trabaja con su cuenta en su copia local y cuando termina los cambios que estaba realizando los sube al repositorio común. Los problemas más comunes al trabajar de esta forma es que pueden aparecer conflictos con las distintas modificaciones. La coordinación en este tipo de trabajo es fundamental para evitar dichos problemas.

La forma en la que se trabaja con un sistema de control de versiones se llama workflow o flujo de trabajo. Existen diferentes formas de trabajar con un SCV y por lo tanto diferentes tipos de flujo de trabajo. A continuación se comentarán los más frecuentes:
repositorio centralizado

SCV con flujo de trabajo centralizado

Flujo de trabajo centralizado o workflow centralizado. Es un sistema muy propio de la vieja escuela. Se suele utilizar un servidor centralizado y los desarrolladores van publicando sus actualizaciones de código en él. Estos sistemas funcionan de forma exclusiva, lo que implica que si alguien está modificando un elemento ningún otro desarrollador puede realizar actualizaciones del mismo.


repositorio común

Workflow con gestor de integración

Flujo de trabajo con gestor de integración. En ocasiones, para un mayor control sobre las versiones del proyecto se utiliza un gestor de integración que suele ser una persona del equipo de desarrollo que actualiza los trabajos en el repositorio común. Algo parecido a un guardia de tráfico. Los desarrolladores actualizan sus repositorios públicos y es el gestor de integración el encargado de actualizar el repositorio común con los trabajos públicos independientes de los desarrolladores. Este sistema suele ser muy utilizado en SCV distribuidos.

Workflow con tenientes y dictador

Workflow con tenientes y dictador

Flujo de trabajo con dictador y tenientes. Este tipo de flujo de trabajo se utiliza solamente en casos de proyectos masivos (como por ejemplo la evolución de un kernel de Linux). Es una evolución del modelo anterior. En proyectos muy grandes existen varias personas supervisoras de varias partes del proyecto llamadas tenientes y una persona llamada dictador que puede actualizar los cambios que sus tenientes le envían. En este sistema todos los desarrolladores tienen acceso al repositorio para poder clonarlo y crearse su propia copia del mismo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>