Azure DevOps, Visual Studio, GitFlow y otras técnicas del montón

En esencia, soy muy curioso. Es por ello que, siempre que veo, leo o escucho acerca de algo que despierta mi interés, no paro hasta que lo comprendo y si finalmente me provee un beneficio, hago lo posible por incluirlo en mi portfolio. Esto es algo que me sucedió, ya hace un tiempo, con DevOps.

Mi interés por DevOps podría parecer, en un primer momento, algo raro. Es decir, que una persona centrada en Datos como yo, sienta que DevOps le puede servir de mucho, no debe ser muy habitual. Digo ésto, porque rara vez encuentro proyectos de Datos que incluyan el uso de herramientas como Visual Studio, Git, Azure DevOps,… en vez del tradicional SSMS.

Si bien, en este artículo no voy a hablar acerca de cómo utilizar Visual Studio como principal herramienta de desarrollo en el entorno de dato, sí que quiero profundizar en el uso de GitFlow como estrategia de ramas en el desarrollo. Pero, ¿qué caracteriza a GitFlow? Es una estrategia de desarrollo en ramas que fue introducida en 2010 por Vincent Driessen. Utiliza un modelo central de servidor denominado ‘Origin’, que permite a cada desarrollador trabajar sobre un clon del mismo, habilitando la posibilidad de utilizar push y pull entre ellos

Fuente: Vincent Driessen, “A successful Git branching model”, January, 2010. https://nvie.com/post/a-successful-git-branching-model

El entorno está formado por un conjunto de ramas con los siguientes nombres y características.

• Las subidas a producción siempre se realizan desde Master.
• Master siempre debe ser estable y encontrarse listo para desplegarse.
• El trabajo siempre se realiza sobre Dev. Poniendo el foco en que el producto sea liberable y disponible.
• La rama de Release viene a ser utilizada para estabilizar el desarrollo.
• Cuando desarrollamos una característica, esta se realiza sobre una rama Feature.
• Los miembros del equipo pueden trabajar conjuntamente sobre esa rama Feature.
• Las ramas Feature siempre hacen merge con Dev.
• Las ramas Feature siempre se eliminan después del merge con Dev.

Existe una rama llamada Hotfix para resolver problemas críticos de producción. Además, esta nueva rama será fusionada con Master y Dev tan pronto se solucione dicho inconveniente.

Una vez realizada esta breve introducción, pasaré a comentar cómo poder implementar el uso de esta estrategia en Visual Studio 2019. Para ello, lo primero que hay que hacer es instalar GitFlow desde el Marketplace de Visual Studio 2019.

Una vez instalado, sólo deberemos verificar y mapear las ramas por defecto con sus correspondientes nomenclaturas en nuestro desarrollo. En nuestro caso, cambiaremos el nombre de la rama Development, incluyendo dev.

Ahora ya disponemos de la posibilidad de crear tanto nuestras ramas Feature como la de Release e ir completando nuestro proyecto con los sucesivos commits.

En el ejemplo vamos a crear la rama Feature con el nombre 1234-crm-staging. Para ello, sólo debemos pulsar en Team Explorer, GitFlow, Start Feature y nombrar. Una vez completado estos pasos, sólo queda presionar Create Feature para completar la tarea. Sencillo.

Si vamos a las Branches, veremos que aparece una nueva carpeta con el nombre de la Feature recién creada desde Dev. Aquí la tenemos. Incluso comentar que si pulsas sobre la historia de la nueva rama, podrás ver que está alineada con Dev, puesto que ha sido recién creada desde dicha rama.

En estos momentos, realizo una modificación sobre la rama y realizo el commit. Y conseguido, hemos subido nuestro código de la rama 1234-crm-staging.

Ahora realizo el merge desde 1234-crm-staging a dev. Para ello me voy a GitFlow y selecciono la rama Feature, pulso sobre Others y selecciono el check de Rebase on Development branch. Eso finaliza mi Feature y la elimina del desarrollo integrándola en dev.

Y terminado. Tenemos nuestro entorno con las ramas Dev y Master disponibles para seguir trabajando en el resto de características de nuestro proyecto.

CONCLUSIÓN
El uso de Entorno de Desarrollo Integrado como Visual Studio no sólo es cosa de desarrolladores de aplicaciones, también es muy válido para casos de Arquitectura de Datos y yendo más allá, para Ciencia de Datos incluso. Es por eso, que desde mi punto de vista es necesario profundizar en el uso de Azure DevOps como sistema de buenas prácticas.

En próximos artículos hablaremos de la Integración Continua y el Despliegue Continuo. Como dicen que vale más una imagen que mil palabras, os dejo este recorte para abrir boca de lo que sería la CI de una base de datos.