Scrum, Agile, Docker y Orquestadores (revisado).

¿Que tiene que ver una metodología de desarrollo del software con los contenedores? Pues a priori parece que nada, pero en realidad todo, a mi juicio.

 ¿Qué aporta agile al desarrollo del software? Certeza. ¿Qué necesita esta metodología para ser implementada? Que los entornos sean automatizados, fiables y además de que sean estables. 

Pongamos por caso el desarrollo de una aplicación de ERP que deseamos desarrollar con un framework de un lenguaje y que queremos que nuestro cliente use desde la primera publicación. Es evidente que no podemos desarrollar la aplicación en un tiempo corto pero si demostrar al cliente que podemos ir entregando funcionalidades de ese nuevo ERP en periodos cortos, además de que podemos: 

a. minimizar los errores de código, cualquier error es detectado en los entornos previos, de forma automática

b. demostrar al cliente, antes del despliegue en producción, que las nuevas funcionalidades se comportan de forma deseada

c. mostrar un roadmap de desarrollo cierto, 

d. implementar de forma "ágil" los nuevos requerimientos y 

e. corregir los errores detectados en anteriores entregas, 

f. planificar los nuevos requerimientos de negocio y la plataforma que será necesario para su implementación. 

Para ello necesitamos un entorno en el que desplegar sea cuestión de minutos y no dependamos de grupos ajenos a los de desarrollo para ello, ya que estos grupos suponen cuellos de botella además de ineficiencias de tiempo y de costes. 

También necesitamos políticas claras de como gestionar el código, estas políticas giran siempre en torno al ideal del GITFLOW, una política que se define por:

1. un código en producción, rama,  que se modifica solo en cada entrega que ha pasado por todos los controles, 

2. un código de desarrollo, una/s rama/s diferente/s, el cual es constantemente testeado cuando:

   2.a. se entrega una nuevas funcionalidad del software, para ser probadas antes de su despliegue en producción, 

   2.b. se entrega una corrección de un bug detectado en el código de producción 

3. un código de desarrollo de funcionalidades, que es testeado en cada prueba, y si pasa los controles de calidad y test, se propone como candidato a ser considerado como código de desarrollo.

Lo descrito genera una política de desarrollo, inicial que está sujeta a modificaciones, dependiendo del proyecto a implementar.   

Todo lo anterior se puede implementar gracias al esfuerzo que ha sido desarrollar  la tecnología subyacente: los contenedores, los orquestadores de contenedores, la tecnología que hace posible los contenedores como cgroups, fuse, ... Todo ello enfocado a la entrega de versiones incrementales de una aplicación "atomizada" en funciones que son las responsables de dar una respuesta ágil a las necesidades de nuestros clientes. 

Para ello se ha ido buscando un mecanismo, cada vez más refinado, de llevar desde el entorno de desarrollo al entorno de producción ese código, de tal manera que se ha ido echando manos de diferentes herramientas, tecnologías y conceptos de desarrollo de software. 

Planteemos el paradigma:

1. tenemos un entorno de desarrollo, automatizado en la integración (CI),y  en el despliegue y pruebas (CD)

2. tenemos un enfoque de desarrollo basado en desarrollar aplicaciones simples que interactuan entre ellas para crear una experiencia de usuario rica, 

3. tenemos un roadmap claro de las funcionalidades  a implementar, el como y el cuando se han de entregar

4. tenemos un entorno tecnológico lo suficientemente estable para desarrollar y lo suficientemente ágil para integrar nuevas tecnologías, 

5. una política definida de como se debe gestionar esa entrega de valor al cliente

6. una infraestructura, propia (on-premise, cloud privado) o contratada en cloud público (máquinas virtuales en la nube, cluster de kubernetes, u otro orquestadores), con las herramientas de:

   a. repositorios de código, propio o de terceros,

   b. acceso a repositorios de imágenes, propio o de terceros,

   c. herramientas de seguridad, para el control del código y sus vulnerabilidades, 

   d. herramientas de CICD, para la automatización de las fases de integración continua (CI) del código para que sea candidato a ser publicado, y de despliegue continuo (CD) para su publicación, y testing si es necesario, de los productos de software

   e. herramientas para almacenar los productos de software, repositorios de objetos de software, que serán usados por las herramientas del punto d. ,

   f. una infraestructura, ya se ha indicado privada/publica para desplegar los objetos almacenados en el punto e. con la herramienta del punto d. 

   g. unas herramientas para el almacenamiento y  acceso a los logs y la monitorización para el diagnóstico de las aplicaciones desplegadas en la infraestructura del punto f. 

Con todo lo anterior tenemos la posibilidad de integrar en grupos colaboradores formados por: desarrolladores, implementadores, testeadores, y un grupo de apoyo para la infraestructura. Todos los anteriores grupos tienen acceso a la monitorización (que es una herramienta de ayuda al diagnóstico) y los logs centralizados, verdadera herramienta para la diagnosis de los errores que se presenten en las aplicaciones. Desaparecen muchos grupos que aportan poco valor a la operativa como: los operadores, los equipos de vigilancia de monitorización, y grupos similares. Recogen sus funciones, de los anteriores grupos,  los automatismos de monitorización, y los grupos de aplicación que además de desarrollar el código también deben de dar soporte al mismo en los momentos de incidencia. 

Por otro lado los grupos de calidad del software que en algunas organizaciones habían nacido para controlar el pobre desempeño de los grupos de desarrollo a la hora de la integración y el despliegue, hoy en día son minimizados sus cometidos ya que muchas de sus tareas están automatizadas con las pruebas de QA. 

Con esta visión podemos, sin la menor duda, entender la fuerte interrelación entre SCRUM, Agile la tecnología de Docker y Orquestadores.