a

Somos una startup de tecnología dedicada a la transformación digital. Especializados en desarrollo de aplicaciones móviles, desarrollo web a medida y marketing digital.

Últimas noticias
Síguenos
Armadillo Amarillo > Tecnología  > Trabajo en equipo: Control de Versiones

Trabajo en equipo: Control de Versiones

¿Alguna vez te ha pasado que has estado trabajando en algo y que hay un momento en el que llegas a un punto donde no te gusta lo que has hecho y quieres volver atrás pero no puedes porque el «Control + Z» no da para más?

¿Alguna vez has guardado tu código en Drive/Dropbox y por casualidades de la vida se te borra el proyecto o se te olvida la contraseña o se te acaba el espacio en el disco?

¿Trabajas en equipo y tenéis que ir pasándoos el proyecto cada vez que hacéis una modificación? Y luego viene el lío de unir las versiones de cada uno…

Estos y muchos otros problemas se pueden evitar usando un control de versiones. Hoy te explicamos cómo.
285

Con palabras más técnicas: ¿Qué es el control de versiones, y por qué debería importarte?

El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante.

Si eres diseñador gráfico o web, y quieres mantener cada versión de una imagen o diseño (algo que sin duda quieres), un sistema de control de versiones (Version Control System o VCS en inglés) es una elección muy sabia. Te permite revertir archivos a un estado anterior, revertir el proyecto entero a un estado anterior, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que puede estar causando un problema, quién introdujo un error y cuándo, y mucho más.

Usar un VCS también significa generalmente que si se corrompen o pierden archivos, puedes recuperarlos fácilmente. Además, obtienes todos estos beneficios a un coste muy bajo.

Os vamos a hablar de cómo lo hacemos nosotros. Usamos Git, que funciona localmente (en tu propio sistema) y remotamente (en el servidor o en la nube):

  1. Repositorio Local: Se genera una base de datos de cambios sobre los archivos del proyecto Git que va registrando absolutamente todos nuestros cambios pudiendo acceder a cualquier cambio.
  2. Repositorio Remoto: Los repositorios remotos son versiones de tu proyecto que se encuentran alojados en Internet o en algún punto de la red.

Sabiendo esto… ¿Como trabajamos en Armadillo Amarillo?

Tenemos siempre dos ramas: una master con el código fuente de producción (el que siempre debe funcionar con parámetros de producción) y otra rama develop donde se integran todos los desarrollos de las historias de usuario. Para ello, usamos Gitflow de forma que, cada vez que de la pizarra de JIRA un usuario se asigna una historia de usuario:

  • El usuario se asigna la historia de usuario en JIRA y la mueve a “En progreso”.
  • El usuario crea una rama nueva en Git usando la función “Nueva funcionalidad / New Feature” de Gitflow. El nombre de la rama debe coincidir con el nombre clave de la historia de usuario de JIRA.
  • Durante el desarrollo de esta funcionalidad se van subiendo los cambios al repositorio remoto para que se quede en el server y si por cualquier caso otro compañero necesita seguir con esa funcionalidad no tiene que empezar desde cero.
  • Durante el desarrollo de esta funcionalidad se van subiendo los cambios al repositorio remoto para que se quede en el server y si por cualquier caso otro compañero necesita seguir con esa funcionalidad no tiene que empezar desde cero.
  • Cuando se termina el desarrollo de la historia de usuario se cierra la rama con la función “Terminar funcionalidad / Close feature” de Gitflow. Marcando además «Borrar rama / Delete branch«, porque si un compañero necesita hacer cambios en esa funcionalidad, al abrirla usando el Gitflow, coge los cambios actualizados con develop.
  • Una vez hecho lo anterior, será necesario hacer push de los cambios de la rama develop y así quedarán totalmente integrados en la rama.
  • Se mueve la tarea a “Terminada” en JIRA.

En caso de bloqueos en el desarrollo, se mantiene la rama de la historia de usuario hasta que se pueda completar el desarrollo. Lo que sí es importante es mover la tarea de JIRA al estado Bloqueado para que quede constancia de ello y avisar al resto del equipo y al scrum master.

Por último, te recomiendo que uses SourceTree como herramienta de Gestión de Git si no usas ninguna, ya que ésta es muy eficaz.

 

 

Desarollo apps y platafromas web

Jesus Lopez

Armadillo Habilidoso. Experto técnico en todas tecnologías habidas y por haber. Responsable de los Armadillos Habilidosos, amante de la música, las motos y Geek a más no poder.

No Comments

Leave a reply