Cómo mejorar el canal DevOps. Primeros pasos.

Todas las organizaciones que usan software tienen un canal DevOps. El canal DevOps se define aquí, como el proceso establecido para el control y gestión del ciclo de vida completo del software. El ciclo de vida contempla desde la concepción, el desarrollo y la puesta en marcha, continúa con el mantenimiento y termina con la eliminación. En el camino de este proceso se hacen instalaciones, se realizan pruebas, se usan herramientas software y otras, se realizan tareas manuales, se hacen revisiones, se crean o modifican entornos, se manejan repositorios de código y documentaciones, etc.

Este canal Devops será más o menos caótico, estará documentado o no, funcionará mejor o peor, pero ahí está, todas las organizaciones que usan software lo tienen. Lo que se propone en este post son ideas a tener en cuenta para mejorarlo. Cada instalación es distinta y por esto el canal DevOps no es estándar, pero para conseguir un buen canal es interesante tener en cuenta las prácticas que están funcionando en importantes organizaciones. Aquí se  presentan algunas de estas prácticas de éxito para que puedan ser tenidas en cuenta por aquellos que decidan mejorar el canal DevOps.

Crear las bases para el canal DevOps

Los desarrolladores crean el código en sus puestos de trabajo, aislados de los entornos de pruebas y los productivos. Este código una vez escrito y probado de forma aislada, se integra con el código de los otros miembros del equipo. La integración del código no es cosa sencilla, esta integración supone que el código de varios desarrolladores tiene fundirse en un código único que lleve a cabo la misión para la que ha sido construido. Para facilitar esta integración se usa un repositorio donde todo el código se almacena y donde cada desarrollador acude para integrar lo construido y para descargar código que haya que modificar para mejorarlo o repararlo.  Es muy importante que el repositorio sea único, siendo la fuente de confianza. En el repositorio está depositado el trabajo de todos los miembros del equipo, correctamente integrado.

Es importante también modificar la definición de hecho para que tenga incluido el despliegue y puesta en marcha de los aplicativos en entornos de tipo productivo. Hay que tener en cuenta que un aplicativo no está dando servicio hasta que no está en producción y el canal DevOps no se ha recorrido completo hasta ese momento.

Construir pruebas automáticas que sean rápidas y fiables

Los desarrolladores están continuamente creando código y modificando código existente, es su trabajo. Las pruebas automáticas preservan el código, cuando los desarrolladores lo modifican les sirve para comprobar que todo sigue funcionando correctamente. Al estar automatizadas es fácil ejecutarlas y si están hechas adecuadamente además es rápido. Cada vez que el código se modifica se ejecutan las pruebas para asegurar que no se han introducido errores o disfunciones. También sirven estas pruebas para comprobar que todo va bien cuando el código se despliega en un entorno, o se modifica algún elemento que pueda afectar al funcionamiento. Es interesante tener en cuenta la técnica Test Driven Development (TDD), esta forma de desarrollo asegura que cuando se implementa una funcionalidad, esta tiene una prueba asociada. TDD tiene otras muchas ventajas según sus defensores entre los cuales se encuentran reconocidos expertos.

Otra técnica a tener en cuenta es el Andon Cord. Es un principio de fabricación Lean, promueve la  notificación al equipo y la dirección cuando se produce un problema en el proceso o en la calidad del producto fabricado. La idea es parar la cadena de producción para solucionarlo antes de continuar. En el canal DevOps, esto se puede aplicar a por ejemplo al descubrimiento en el entorno de pre-producción de un código que no cumple las reglas de calidad estática de código. ¿Debemos parar el despliegue? Así evitamos introducir deuda técnica en el aplicativo. Esta es una política que deberiamos tener acordada y a ser posible automatizada.

Promover la integración continua

Está sobradamente demostrado que hacer desarrollos de larga duración que se abordan separando el código de la rama principal del repositorio, no es práctico. Pasado el tiempo los problemas de integración son complicados de resolver sino insalvables. Hay prácticas de desarrollo que establecen como trabajar sin hacer ramas en el repo. Si se decide trabajar con ramas que el tiempo que transcurre trabajando en una rama tienda a ser lo más corto posible.

Conseguir versiones de bajo-riesgo

Esto se refiere a realizar actividades que aseguren que cuando una versión se ponga en funcionamiento, no se produzcan problemas. Una técnica que se puede emplear son los "Dark Launches", esto consiste en poner en producción funcionalidades que se ocultan a los usuarios mediante mecanismos de programación. Estas versiones ya desplegadas pero no utilizadas, permiten poner a prueba su uso por parte de los desarrolladores, antes de liberar su uso para el resto de los usuarios. Cuando definitivamente se libera, hay bastantes garantías de que funcionará.

      Preparar la arquitectura para versiones de bajo riesgo

La arquitectura seleccionada para el sistema debe facilitar la productividad, testabilidad y seguridad. Esto se debe tener en cuenta a la hora de elegir, marcos de desarrollo, bases de datos, etc. teniendo en cuenta las facilidades conque cuentan los equipos que en la arquitectura elegida.

Además en cuanto a la arquitectura, muchas organizaciones comparten sistemas heredados con sistemas de nueva creación. Las arquitecturas de los sistemas heredados tienden a ser monolíticas, mientras que los nuevos tienden a ser orientadas a microservicios. Si se decide mejorar un sistema antiguo por uno nuevo basado en microservicios, tener en cuenta en patrón "Strangler" para poder realizar el cambio poco a poco.

En conclusión      

Mejorar siempre es posible. El canal DevOps es la forma mediante la cual las organizaciones pueden hacer llegar el software que desarrollan a sus usuarios. Es importante hoy en día en un mundo de negociós tan dinámico y cambiante, ser capaces de manener los sistemas al día, tanto modificando su funcionalidad cómo consiguiendo que den servicio 24 horas al día y 365 dias al año. Mejorar el canal DevOps ayudará.

Es conveniente preparar un ciclo periódico de mejora continua (Ciclo de Deming). Por ejemplo anualmente, semestralmente o a demanda. El objetivo es realizar los pasos 1 al 4 de forma repetida lo que implica estar revisando y mejorando de forma constante.

                                                

La fuente de inspiración de este post está en “DevOps Handbook” de Gene Kim y Jez Humble.