El ciclo de DevOps, una guía para iniciarse en las fases que lo componen

Hay términos que están de tendencia, tienen mucha capacidad de empoderamiento, y generan movimientos renovadores en las compañías. Sobre todo, las dedicadas a negocios relacionados con la economía digital.

Uno de ellos es, así como microservicios, Agile, o bien transformación digital, el término DevOps.

Este es un término, casi una filosofía, del que en el artículo voy a centrarme en la descripción de las fases del ciclo iterativo que lo componen; con la meta de aclarar conceptos básicos que debo tener interiorizados ya antes de emprender su adopción.

Fases en DevOps

Hoy día, DevOps se puede delimitar como un símbolo de infinito o bien un circulo que define las distintas áreas y fases que lo componen:

Plan
Desarrollo
Integración continua
Despliegue
Operación
Monitorización
Es esencial entender que es una de las varias representaciones, no el canon terminante. Habiendo simplificaciones completamente válidas en forma de 4 fases primordiales, o bien descomposiciones detalladas de cada una de ellas.

Otra idea indispensable de interiorizar es que se trata de la definición de un flujo iterativo, por lo que diferentes procesos pueden estar comprendidos en diferentes fases de forma orgánica y sobrepuesta, siempre y en toda circunstancia ajustándose a los conceptos esenciales de valor y mejora continua.

Debo eludir caer en la tentación de considerarlo como un ciclo en catarata, en donde las fases están acotadas rígidamente por una frontera que las aparta, o bien que únicamente se puede comenzar una fase cuando la precedente ha finalizado totalmente.

Ahora, miraré con más detalle cada fase, permitiéndome una licencia muy frecuente en los procesos DevOps, que es emplear el framework Scrum (y sus arquetipos) como metodología de trabajo para hacer más fáciles las explicaciones.

Gestión y planificación

Todo proyecto precisa una visión que indique a los participantes -sean directos o bien indirectos- el motivo y fin último del trabajo a realizar; definiendo un conjunto mínimo de funcionalidades que dejen aportar Valor en todos y cada iteración, los criterios de aceptación a cumplir y la definición de acabado; para cada una de las fases y en el conjunto del proyecto.

Esto se forma como una Pila de Producto viva, que está aguantando continuadamente un proceso de “jardinería”, desde determinado punto de vista de negocio, la que nutre a las distintas fases de desarrollo y operaciones; y que aborda los cambios y evoluciones conforme un proceso de mejora continua basado en un retroalimentación temprano y continuado.

Para esto utilizare las “liturgias” de Scrum, como son las asambleas de Planificación de la iteración y la Revisión de la iteración; mas sin, por este motivo, parar de tener una comunicación y también implicación incesante entre negocio y el equipo técnico. Siendo indispensable que Negocio y Administración se formen en las herramientas y métricas diseñadas a fin de que tengan una visibilidad veraz y suficiente del desarrollo del proyecto.

Desarrollo, edificando código

Esta fase es en donde se edifica. Sea picando código, diseñando infraestructura, automatizando procesos, definiendo las pruebas o bien implantando la seguridad.

Es en donde, actualmente, se está efectuando el ahínco más esencial en la automatización de las acciones repetitivas o bien complejas; y que hubiera de ser uno de los primeros escalones que escalar para implantar DevOps en una organización.

Si tuviese que resumir en una palabra el término más esencial de esta fase, esta sería “pruebas”.

Así sea en una aplicación de administración, operaciones con datos o bien el despliegue de infraestructura virtual; siempre y en toda circunstancia trabajaré en código – así sea con un lenguaje de programación o bien de scripting; el que ha de ser guardado en un gestor de código que me deje operaciones básicas como históricos, ramas, versionado, etcétera

Mas con esto no es suficiente y cada pieza construida debe incluir (obligatoriamente) sus pruebas automatizadas. Esto es, los mecanismos con los que el propio sistema pueda cerciorarse de que lo que hemos efectuado es adecuado, no falla, no hace fallar a otras partes, cumple los criterios de aceptación, y apunta de manera temprana los fallos que brotan en todo desarrollo.

En verdad, este es un camino imperativo para adoptar Devops, desde sus más incipientes estadios.

Primero almaceno el código/script en un gestor para poder tener versionado y poder hacer rollback; entonces comenzar a incluir las pruebas automatizadas, lo que va a generar una transformación profunda en las técnicas de codificación (desacoplamiento, segregación, modularización, etc); para finalizar, se llega a la orientación de lo construido hacía las fases siguientes, incluyendo la transformación del propio flujo de trabajo.

Integración continua, o bien de qué manera dormir tranquilo

Si bien en esta fase y la precedente la mayor parte de los autores nos centramos en un punto de vista de desarrollo, verdaderamente la llegada de DevOps y los conceptos de Infraestructura como código, hacen que IT asimismo sea pleno partícipe de esta fase.

La integración continua es mecanizar el mecanismo de revisión, validación, prueba y alarmas del valor construido en las iteraciones, desde determinado punto de vista global.

O sea, mi singular funcionalidad o bien característica, que he construido en mi ambiente de desarrollo, así como las pruebas automáticas que aseguran su adecuado funcionamiento, son publicadas en un servicio que la integra con el resto de la aplicación.

De esta manera, lanzando todas y cada una de las pruebas que incluye cada funcionalidad, más las pruebas de integración de toda la aplicación, más las pruebas funcionales, más las pruebas de aceptación, más los análisis de calidad del código, más las pruebas de regresión, voy a poder estar seguro de que mi aplicación prosigue marchando apropiadamente.

Y si algo falla, brincará la alarma temprana señalando exactamente en qué pieza y exactamente en qué línea rompe mi sistema.

Con lo que, cuanto más me acerque al instante de empezar el camino crítico del despliegue, más apacible voy a estar por el hecho de que más pruebas incluyen mi trabajo.

Despliegue automatizado

Desplegar, en las organizaciones tradicionales, siempre y en todo momento ha sido un dolor. 2 papeles (Dev y también IT) con objetivos y también intereses discordantes se hallan en una batalla de incomunicación y recelo mutuo para publicar la aplicación en los diferentes ambientes de trabajo: desarrollo, integración, calidad/test, preproducción, producción, etcétera

Como en toda cadena, es simple romper por el eslabón más enclenque, y cuantos más pasos existan en los procesos de despliegue, más posibilidades de fallo humano se aúnan.

De esta manera, DevOps fomenta la automatización de los despliegues a través de herramientas y scripts, con la meta último de que todo el proceso se resuelva con un botón de aprobación o bien, idealmente, la activación de una característica.

Entre cada ambiente de despliegue, hay que tener muy en consideración la administración del contexto (crear, configurar y destruir ambientes); efectuar y superar las pruebas concretas de cada uno de ellos (como pueden ser pruebas de desempeño, resiliencia, funcionales, de seguridad o bien de UX); y regentar la administración de la configuración (CMDB) conforme con las complejas necesidades de los diferentes contextos de despliegue.

Lo más crítico y difícil en esta fase, más que famosa y adoptada en el ambiente IT, es la llegada del término Cloud con sus capacidades de Infraestructura como código, que fuerza un cambio en el paradigma de la administración de la infraestructura. Que pasa de una administración de recursos finitos a una administración basada en una optimización permanente de costos.

Operaciones, velando por el buen funcionamiento

Es una minoría las aplicaciones que son puestas en producción y no precisan de un trabajo incesante en su optimización, evolución, o bien soporte. Mas, además de esto, debo tener en consideración todas y cada una de las operaciones relacionadas con su funcionamiento que deben efectuarse de forma continuada a lo largo de toda la vida del software.

De esta manera voy a tener, el ajuste de los recursos conforme con la demanda o bien las peculiaridades de desarrollo de las aplicaciones; la modificación activa de la infraestructura por causas de seguridad, desempeño, disponibilidad, etc.; o bien la optimización de procesos y procedimientos que requieren cambios en el contexto de ejecución y explotación.

En esta fase, va a aplicar como anillo al dedo la adopción del término de Nube – sea pública, privada o bien hibrida- dónde las operaciones puedan explotar las capacidades de escalabilidad, persistencia, disponibilidad, transformación, resiliencia y seguridad que ofrecen esta clase de plataformas.

Debiendo trabajar en la automatización de la optimización de los escenarios de operaciones, de manera que vuelvo a atenuar los fallos a raíz de fallo humano.

Monitorización, o bien el arte de medir

Esta última fase de un proceso DevOps, es una fase permanente y que se aplica a todo el ciclo completo.

Es dónde voy a delimitar las medidas que voy a estar controlando para supervisar el estado de salud de las aplicaciones y su infraestructura, siendo esto el histórico de las mediciones a lo largo de un periodo de tiempo, que me muestran la evolución del sistema.

Tiene una vertiente reactiva, en donde conforme con los resultados voy a ir ajustando o bien alterando la plataforma; y otra proactiva en la que un proceso de aprendizaje progresivo me va a permitir adelantarme a las necesidades y peligros.

Lo que no se define no se puede medir. Lo que no se mide, no se puede progresar. Lo que no se mejora, se degrada siempre y en toda circunstancia. William Thomson.

Mas no todo es tecnología, y en esta fase se marcha a afianzar el retroalimentación progresivo de todos y cada uno de los campos y niveles del ciclo Devops para poder incluirlos en la próxima iteración a lo largo de la fase de Plan, o bien inmediatamente con correcciones puntuales.

Controlaré, examinaré y voy a medir todo lo que me pueda aportar una visión general del estado actual del proyecto (en su definición más extensa), incluyendo todas y cada una de las dependencias que tuviera; mas con capacidades de bajar hasta la peculiaridad para observar detenidamente el funcionamiento de una pieza particularmente.

Y a través de la realización de retrospectivas, completaré el proceso de Kaizen (mejora continua) del proyecto, incluyendo todos y cada uno de los orígenes relacionados con el desarrollo positivo de los trabajos.

Sobre las fases del ciclo DevOps

He mostrado una visión extendida y también idílica de un ciclo DevOps completo, siguiendo una estructura lógica basada en la experiencia y en la profusa literatura que hay publicada.

La realidad es más compleja tanto en la implantación como en la ejecución; mas indudablemente el mayor escollo son los inconvenientes de comunicación entre los equipos con objetivos y también intereses diferentes, y la falta de confianza de salir de mi zona de confort siguiendo una “moda”.

No obstante, las ventajas son fundamentales. Y no solo en el campo de la productividad, del Time to Market, o bien de la flexibilidad de la compañía en frente de las demandas del negocio y los clientes; si no asimismo en los factores humanos, de mejora de la calidad de vida, que hay que valorar en su justa y positiva medida.