Praxis de Devops (revisado 26/6/2022).

En mis últimos dos años de experiencia he encontrado que aplicar DevOps es más difícil de lo que parecer . 

Existe cierta resistencia en los grupos de desarrollo por aplicar este modelo ya que entiende de que se les carga de trabajo al implantar este modelo. Cuestión que entiendo que es contraproducente ya que aceleran los tiempos de despliegue a la par que facilita los diagnósticos de errores tanto a la hora de integrar los productos como desplegarlos en los entornos previos y de producción. Si bien es cierto que los grupos de desarrollo tienen que incrustar en sus equipos perfiles más orientados a la gestión de la configuración de los servicios. 

Entiendo que aplicar DevOps sin contar con especialistas como los de QA que deben negociar las directrices de despliegue y calidad de los mismos a los demás miembros de los grupos implicados , cuales son los hitos a superar y como marcar el desarrollo como "preparado" para ser desplegado en producción. Y todo lo anterior de forma automatizada, sin que haya un factor humano falible en el proceso para que pueda pasarse un código de "candidato" a "entregable" con solo pulsar un botón.

  

DevOps depende completamente de Gitflow y de la  gestión de ramas. Lo novedoso de este sistema es aunar la automatización con las prácticas de agile/scrum/kanban de que toda iteración del código debe: ser probado, y que además con ello se obtiene la entrega de valor al cliente. 

Con la automatización se permite a los diferentes miembros del grupo de desarrollo focalizar los esfuerzos en implementar y mantener las aplicaciones acortando los tiempos de despliegue porque están automatizados, a la par que están comprobados los incrementos de valor al cliente.

A los grupo de de operaciones se les libera de las tareas del despliegue y sus operativas de las aplicaciones en todos los entornos gracias a la automatización. 

Pasamos a describir este proceso en base a los diferentes entorno, con sus hitos, que nos marcan que código puede "promocionar" al siguiente. Todo ello íntimamente relacionado con una política de ramas de desarrollo definido.

Entendamos este  flujo, conocido como Gitflow , busca de ser un círculo virtuoso, que describimos a continuación:

1. Con el código de las ramas RELEASE, donde se codifican nuevas funcionalidades. Con la petición  de "merge" se ejecutanzan automáticamente  los procesos de "continuos integration" (CI) definidos en la herramienta de despliegue (jenkins, azure DevOps, etc... ) con los siguientes pasos:

• Realización de pruebas unitarias del software, de esta forma se rechaza el código que no pase las pruebas unitarias,  que aseguran la calidad del código desarrollado. Estás pruebas se definen en herramintas soportadas por lo que el grupo de QA y deben de estar alineadas las prubeas con el grupo de desarrollo,
• En el caso de que las pruebas unitarias del código han sido superadas pasamos a la construccion del software en el formato de despliegue de la aplicación (binarios, tar.gz, etc), si se supera entonces hemos pasado la fase de "integración" de los diferentes elementos modificados en la release.
• Subida al almacén de artefactos del producto construido en el anterior punto  correctamente versiónado y tageado para su despliegue en los entorno de desarrollo.
• Despliegue del producto en el entorno de desarrollo para realizar los test de QA, si fuera necesario.   

2. Las ramas DEVELOP son aquellas ramas donde se dan dos situaciones: 

• Son el origen desde donde se crean:
• las ramas release, donde añadimos valor al cliente, 
• las ramas de bugfix / hotfix de los desarrollos ya desplegados en los entorno de preproducción y producción, para resolución de "fallos" en el código desplegado en producción. 
• En esta rama se ejecutan al menos los siguientes pasos:

• Realización de  pruebas de unitarias que aseguren la calidad del código, proveniente de un bugfix, hotfix.
• Construccion del artefacto 
• Subida del artefacto construido al almacén de artefactos, correctamente versiónado y tageado
• Despliegue del artefacto en el entorno adecuado, esto es, en los entornos de preproducción y/o en los entornos de tests
• En caso de que se despliegue de forma exitosa entonces pasamos, pasamos a las pruebas de regresión del código para mantener su calidad.
• Pruebas de que el interfaz de la aplicación responde de forma esperada, estas pruebas también son aditivas 
• Ejecución de las pruebas de rendimiento para comprobar que la subida a producción de la nueva reléase no suponga pérdidas de rendimiento. 
• Superadas todas las anteriores fases con éxito realizamos la petición de la promoción del código a la siguiente rama:
•  si proviene de bugfix/hotfix  se ejecuta la petición, automatizada, para que los responsables promuevan a la rama  develop el cósigo desarrollado, y  
• si es de develop  se ejecuta la misma petición para promover el código a la rama master
• En la rama máster, se han superado todas las pruebas de control:
• Pruebas unitarias,
• Pruebas de integración
• Pruebas de interfaz
• Pruebas de regresión 
• Pruebas de rendimiento
• Los pasos  a dar en  este entorno son:
• Construcción del artefacto,  
• Subida a repositorio correctamente versiónado y tageado, 
• Despliegue en la infraestructura de producción dentro de la ventana marcada para la aplicación. 

Se pretende con todo este ciclo:

•  el dar calidad al software desplegado ya que constantemente está siendo testado y comprobado para corregir los errores de codificación mas comunes para que no sean trasladado a los entornos de preproducción y producción. En caso de ser detectado se rechaza y se informa del error todo ello de forma automática.
• Además se facilita el trabajo a los grupos de operación ya que se libera de realizar los pasos de despliegue por estar automatizados.
•  A la organización se les da una  trazabilidad de las diferentes acciones realizadas sobre la  aplicación de forma que se conozca en las herramienta de gestión  del estado de cada una de las nuevas ramas: features / bugfix/hotfix / releases / develop y master: además indicando en qué estado quedó dichas acciones. 

Se comprende que los grupos de desarrollo son reacios al cambio ya que se les pide que se adapten a nuevas normas de entrega del software y se les pide que generen un código que supere pruebas de calidad del software, así como de test de: regresión, rendimiento, etc... Todo ello enfocado a entregar valor con cada pull request que se realice de un entorno (desarrollo,, integración, preproducción y/o producción ).

Los grupos de desarrollo tienen que estar apoyados por varios roles nuevos que deben de incorporar a sus equipos:

• un especialista en automatización, para dar soporte a  los automatismos necesarios según la infraestructura subyacente para que el despliegue continuo (CD) en cada entorno sea un hecho, 
• un especialista en QA y testing, el cual desarrollará las pruebas:
• unitarias, 
• regresión
• interfaz, 
• rendimiento

    ; que permitan cumplir con los estándares de cada entorno y se promueva el código al entorno siguiente , todo ello de la mano del especialista de automatización para que entre ambos den soporte al grupo de desarrollo con las herramientas necesarias que permitan la automatización de todos los procesos descritos anteriormente. 

El apoyo de los grupos de infraestructura se queda ahora en un segundo plano que es el soporte al grupo de desarrollo en aquellas incidencias que se presenten y donde el software no representa un papel relevante en el buen desempeño del producto, si no que por razones ajenas al mismo este no responde de la forma deseada.

En otro artículo definiremos los nuevos roles entre los grupos de desarrollo y los grupos de infraestructura.