DevOps

Hola, estimados divergentes. En esta ocasión les voy a platicar un poco sobre una metodología llamada DevOps. Este posts va a ser algo denso por la gran cantidad de conceptos involucrados. Sin embargo, aguanten vara un momento. DevOps y sus conceptos asociados son muy importantes porque esa es la manera en que las grandes empresas construyen.

DevOps es la metodología con la que las grandes compañías desarrollan software actualmente.

Ahora bien, no es necesario ser una gran empresa o tener mucho dinero para que nosotros los simples mortales podamos implementar DevOps en nuestros proyectos personales. Como veremos más adelante existen muchas herramientas que son software libre. Adicionalmente, muchas de las herramientas de pago ofrecen versiones gratuitas para la comunidad.

DevOps está al alcance del desarrollador de a pie y le permite desarrollar software de clase mundial.

DevOps es la contracción y combinación de las palabras en inglés “Development” y “Operations” (Desarrollo y Operaciones) y engloba tanto una metodología como una cultura que ayuda a los equipos de desarrolladores a construir software a través de la retroalimentación continua del cliente. DevOps busca acelerar el ciclo de desarrollo de software. Finalmente, de lo que se trata es de reducir costos y aumentar la productividad. El ciclo de DevOps se divide en 8 etapas que forman un ciclo continuo como se aprecia en la imagen.

Las etapas de DevOps

1. Planeación: se toman una serie de características que se desean implementar en el software y se trabaja con el equipo de desarrollo para imaginar cómo se verían esa caracteristicas en el producto.
2. Tirar codigo: Las caracteristicas se van desarrollando y programando.
3. Compilar: Se toma es codigo fuente y se pasa por una etapa de compilación y construcción de una serie de archivos que pueden ser ejecutados por la computadora.
4. Probar: A los archivos generados en el paso anterior se les llama “artefactos” o “artifacts” en inglés. Estos artefactos se prueban a fin de evaluar si tienen la funcionalidad requerida y en busca de errores o “bugs” que puedan comprometer su buen funcionamiento. Las pruebas pueden ser tanto manuales como automáticas. Al proceso de desarrollar pruebas automáticas se le conoce como integración continua. Mientras que al proceso de desarrollar pruebas manuales se le conoce como aseguramiento de calidad o QA por sus siglas en inglés.
5. Liberar: Una vez que el código ha pasado las pruebas unitarias y el cliente esta conforme, se liberan los artefactos. Esta etapa está fuertemente automatizada, sin embargo esto no quiere decir que el desarrollador no haga nada. El desarrollador tiene que mantener una serie de archivos de configuración o scripts.
6. Instalar: En esta etapa los artefactos o unidades de software se distribuyen e instalan en los ambientes de producción
7. Operar: En esta etapa entran cosas como el escalado que consiste en asegurar recursos de hardware suficientes para la carga o el tráfico que la aplicación maneja. O configurar cosas que tienen que ver con problemas de arquitectura.
8. Monitoreo: Es la actividad en la que se vigila que el software esté funcionando correctamente, se toman métricas y se genera estadística sobre el estado de la aplicación.

A final de cuentas se trata de reducir costos y aumentar la productividad. Esto a través de acelerar el ciclo de desarrollo.

Después del paso 8 todo el proceso se repite nuevamente. En esta nueva iteración el cliente provee su retroalimentación y los equipos de desarrollo y operaciones incorporan las lecciones aprendidas en la iteración anterior.

Ingeniería DevOps

La ingeniería DevOps es la aplicación de los conceptos de DevOps en la práctica y está soportada por tres pilares fundamentales:

• Automatización de los “pull requests”: Ayuda al equipo a desarrollar cosas más rápidamente.
• Automatización de las instalaciones (deployments): Ayuda a evitar el problema de “pero en mi computadora si corre”. Evita que los clientes se quejen.
• Evaluación del desempeño de la aplicación: Aquí nos aseguramos de tener una aplicación sana, que responda rápido y que funcione como se espera.

Con la ingeniería DevOps se pasa de la teoría a la práctica.

Parece que hemos regresado a la escuela. ¿Quien no recuerda aquellas materias aburridas? Cargadas de teoría y de conceptos abstractos que hacían que el semestre fluyera de forma muy lenta. Sin embargo, cada una de las siete etapas de DevOps y cada uno de los tres pilares de la automatización están asociados con una serie de herramientas que hacen el proceso muy práctico.

La tabla periódica de las herramientas DevOps

La tabla periódica de las herramientas para DevOps es una recopilación de herramientas organizada muy creativamente como una tabla periódica de los elementos. En la tabla periódica de DevOps cada “elemento” representa la ficha técnica de una herramienta. Estas herramientas están agrupadas por colores y ubicación dentro de la tabla por la función que realizan dentro de un proceso de DevOps. Esta tabla es puramente ilustrativa y de ningún modo es exhaustiva. Sin embargo, nos da una idea de lo que hay en el mercado en estos momentos.

Flujo de trabajo DevOps

Abajo se muestra un ejemplo de un flujo de trabajo en DevOps que emplea algunas de las herramientas que aparecen en la tabla periódica arriba mostrada. También se muestran varias herramientas que no aparecen. Esto es algo muy general, de otra manera el post se convertiría en libro.

Como herramienta de planeación seleccionaremos a ServiceNow en donde se pueden hacer cosas que tienen que ver con la administración de un proyecto, historias de usuario, backlogs para agile, reporte de incidencias, etc.

Java será mi lenguaje de desarrollo puesto que estoy trabajando en un ambiente corporativo aunque podría haber seleccionado Kotlin o Groovy.

El framework de mi elección es Quarkus que promete un entorno de desarrollo simplificado y velocidades de ejecución mayores que Spring Boot o Spring Cloud.

Mi herramienta para logging será Log4J que es muy popular. En este apartado hay mucho de donde escoger como por ejemplo el proyecto Lombok.

No puede faltar en todo buen desarrollo un framework de pruebas unitarias para detectar tantos errores de código como sea posible.

Usaré Mockito para simular dependencias externas y usar estas simulaciones para probar nuestro código. Mockito simplifica el desarrollo de pruebas en clases con dependencias externas.

No me debo de olvidar de la seguridad. No quiero tener nombres de usuario y contraseñas en el código fuente, en los archivos de configuración o regados en los discos duros de mis colaboradores. Voy a necesitar una plataforma centralizada para administración de secretos y manejar solamente variables de entorno en mi código fuente y las configuraciones.

Graddle será el gestor de dependencias y herramienta de automatización de compilaciones (builds) que seleccionaremos.

Para trabajar en el desarrollo de mi aplicación con todas las herramientas arriba mencionadas utilizaré IntelliJ idea como IDE. Hay muchas opciones disponibles en este apartado.

Como herramienta de control de versiones tendremos a git.

Como complemento a Git, usaremos GitLab como repositorio. Pero además, también usaremos gitlab como herramienta de despliegue continuo.

Mi herramienta de pruebas automáticas será Selenium.

Mantendré mis artefactos en Artifactory desde donde podré controlar su distribución.

Como estoy desarrollando microservicios, utilizaré OpenShift como herramienta de despliegue y gestión de contenedores en la nube.

Necesito mantener una estrecha colaboración con mis compañeros así que además del correo electrónico tendré una herramienta de colaboración que funcione en diversas plataformas.

Siempre es importante tomar notas y mantener la mente ordenada. Se puede hacer en una libreta física, a lápiz y papel, pero OneNote también resulta muy conveniente. Todos los posts que he escrito han sido usando OneNote para hacer los borradores.

Por último, dos herramientas de monitoreo. Ambas muy capaces. La primera es AppDynamics que me permite obtener métricas de mi aplicación casi en tiempo real.

La segunda es Kibana que es una herramienta que me permite obtener métricas de los logs que mi aplicación estará escupiendo durante la operación.

Conclusión

Cuando se empieza en el desarrollo de software a nivel corporativo puede ser muy dificil entender como todo encaja en el gran esquema de las cosas. De pronto tenemos que usar herramientas que no sabiamos que existian y que no sabemos porque tenemos que usar. A mi me tomó casi dos años empezar a entender como las piezas encajan en el rompecabezas. No fue hasta que empecé a investigar una herramienta que se llama Jenkins que de súbito comencé a entender como funcionaba todo. El proceso que mantiene todo en su lugar el DevOps