¿Tienes un gran proyecto entre manos y no sabes cómo organizar a todo tu equipo? Existen para esto distintos repositorios remotos a través de los cuales es posible coordinar a todo el equipo. Además de esto, una vez que el proyecto se lanza, como en cualquier proyecto software, surgen una serie de cambios que antes no se habían planteado o simplemente, se quieren añadir nuevas funcionalidades al mismo. Por ello, es recomendable establecer un modelo de trabajo centralizado, en nuestro caso Git Branching.
¿Qué pasaría si el modelo utilizado fuera descentralizado? Nos podríamos encontrar con nuevas funcionalidades integradas que contengan errores o se podría solapar el trabajo de los distintos programadores. Además, si el usuario detecta continuamente errores, la imagen del producto y de la empresa quedaría dañada.
Para evitar esto, en eHidra, nos hemos decidido por esta nueva forma de trabajo en la que las nuevas funcionalidades y los errores detectados tras el lanzamiento, serán revisados una y otra vez hasta que llegue a la visión de los usuarios. ¿Cómo? Utilizando un repositorio remoto como GitHub.
Entornos de trabajo
Para poder hacer todas las comprobaciones contadas anteriormente, necesitamos distintos entornos de trabajo. En nuestro caso, hacemos la siguiente distinción:
- Development: es el entorno al que tendrán acceso únicamente los desarrolladores. De forma que será el primer lugar en el que se comprueben las nuevas características.
- Staging: tras pasar con éxito las comprobaciones del entorno anterior, se volverá a comprobar en éste por si ocurriera algún error que no se haya detectado anteriormente. Hay que tener presente, que justo tras este, pasará a estar en vivo, por lo que es muy importante hacer todos los test posibles. Se le dará acceso a algunos usuarios para que hagan todas las pruebas que crean convenientes.
- Live: es el entorno final, es decir, donde cualquier usuario puede acceder. En él se añadirán únicamente aquellas funcionalidades que hayan pasado con éxito los test que realizados en los entornos de Staging y Development.
Branches
En los repositorios remotos es posible tener recogido todo el código de nuestro proyecto y que éste sea visible por el resto de integrantes del equipo. De esta forma se puede trabajar de manera simultánea. Sin embargo, para evitar lo solapamientos entre los compañeros, GitHub permite crear lo que se conoce como branches. Tendremos entonces 2 branches principales:
- Develop
- Master
En la primera, se encontrarán los cambios que se van a aplicar, mientras que en la segunda estarán el código fuente de lo que está listo para producción.
Habría que distinguir además tres tipo de branches secundarias según el tipo de problema o issue que se vaya a resolver.
- Si lo que se va a hacer es añadir una nueva funcionalidad, la branch en la que se desarrollará formará parte de las Feature branches. Este tipo de branches, una vez que el desarrollador comprueba que funciona, deberán ir a la branch Develop y tras esto, al entorno Development.
- Otro de los tipos de branches que se encuentran en este modelo de trabajo son las Release Branches. Estas se crearán al finalizar un sprint (en nuestro caso, cada dos semanas). Todo lo que haya en ese momento en el entorno development que ya haya sido probado, se volcará en estas branch para pasar al entorno Staging donde se volverá a probar todo de nuevo para asegurarnos de su correcta funcionalidad antes de ponerlo en la web.
- Si la issue que se ha detectado se trata de un error en lo que ya había en la web, se debe solucionar con la mayor brevedad posible y crearemos entonces una branch que formará parte de las Hotfix Branches. Únicamente estas son las que pasarían directamente a la branch master puesto que es necesario que pase al entorno Live de inmediato.
En la branch de develop cada programador irá creando branches secundarias de los distintos tipos para resolver las issues que se van creando en el repositorio remoto. De forma que en cada una de éstas estará todo lo que haya en develop más el código que añada el programador sin que éste afecte al resto de compañeros.
