Nuevo proyecto: Arquitectura de Prueba

Una vez más me meto es cuestiones de automatización de pruebas y una vez más en un contexto bancario. Esta vez junto a mis estimados colegas de Grupo Esfera. Ayer hicimos el kickoff del proyecto y a continuación tuve una de las mejores sesiones de trabajo del año junto a mi amigo Diego Fontdevila. Estuvimos unas 2 horas revisando código, hablando de diseño, trade-offs y herramientas 😉

En términos genéricos el objetivo del proyecto es armar una arquitectura de prueba para facilitar/guiar a los equipos de desarrollo de la organización que trabajan en aplicaciones de canales y que deben integrarse con los sistemas core.

El stack de tecnologías con el que voy a estar trabajando incluye: Cucumber, Selenium, Pact, Java y AS400 entre otros.

Candidate Architecture: OpenShift + Java/Spring + React

I am working in a project with some folks at 10Pines. The client is a big company with operations in most countries of LatinAmerica. From a functional point of view, the project is not so complex, but it has some interesting challenges:

  1. The redesign of  delivery process
  2. The enhacement of the SCM strategy
  3. The design and implementation of a new infrastructure based on OpenShift

In this article I want to focused on points 2 and 3.

Regarding SCM we are using Git (BitBucket) to store code …..and configuration, yes, configuration. We store configuration in a Git repository and make it accesible via Spring Cloud Config. At the same time we manage infrastructure as code, that is: the definition of all the infrastructure is written in code, basically Dockerfiles and other scripts. And of course this is also stored in a Git repository.

Regarding the new infrastructure we are using Docker on Kubernetes, or more specifically OpenShift. We consider we are taken too much risk, so we are not using all OpenShift features, for example we are not using the integrated Jenkins or the configMaps. We continue using our previous build process with some minor extensions, that is: our old and solid Jenkins takes care of the CI process, when we have a feature ready we build the corresponding artifact and publish it in Artifactory. Then Jenkins interacts with OpenShift to trigger the build of the corresponding Docker Image. The process of building the Docker image runs inside OpenShift and implies downloading the corresponding artifact from Artifactory. Once the new image is built and publish, a new deployment is automatically triggered. The following picture represents our build pipeline.

openshift_2

In terms of runtime, our application includes 2 artifacts: a RestAPI (built on Spring-Boot) and a React application (that is served by Nginx). Each of these artifacts is packaged into a Docker container. Finally we have 2 pods, each of them runs 2 docker containers: one that contains part of the application and another one that runs Spring Cloud Config. The following picture shows a summary of this runtime architecture.

 

It worth e mentioning that Spring Cloud Config container is instantiated in each pod but it is only accesible inside the pod.

To be continue…

 

 

Proyecto fallido (porque no solo de los éxitos se aprende)

Hacia fines del año pasado una empresa con la que estaba trabajando me pedió que me encargara de automatizar los tests de una aplicación. Como yo ya estaba comprometido en otro proyecto con otro cliente, solo tenía disponible una dedicación reducida de 1 día por semana. A pesar de esto, el cliente quiso que yo me encarga de esa tarea y así lo hice.

La aplicación en cuestión ya estaba productiva y recibía actualizaciones frecuentemente. La idea era que yo avanzara con la automatización de tests trabajando de forma desacoplada del equipo de desarrollo. Y creo que ese fue precisamente uno de los errores. La aplicación no había sido diseñada considerando la testeabilidad lo cual llevó a que me cruzara con una importante cantidad de trabas al intentar automatizar.  Algunas de esas trabas eran esperables, pero al estar trabajando 1 día por semana y sin una dedicación explícita del equipo de desarrollo para darme soporte, el grado de avance semanal fue muy lento, a punto tal que fui yo mismo quien le propuso al cliente terminar el proyecto. A mi entender esta iniciativa requería: una persona full-time (o al menos con una dedicación de 20 horas semanales) y un tiempo explícitamente reservado del equipo de desarrollo.

Haciendo un análisis de lo ocurrido he podido identificar una situación en común con otro proyecto fallido en que participé tiempo atrás: iniciativa técnica con un baja dedicación mía y sin involucramiento explícito del equipo de desarrollo. La lección aprendida es: no involucrarme en proyectos donde no haya una dedicación explícita del equipo de desarrollo y donde yo no pueda dedicar un mínimo de 15 horas semanales.

Descubriendo OpenShift

Recientemente la gente de 10 Pines me invitó a participar en uno de sus proyectos para dar una mano con las cuestiones de infraestructura. Resulta que lograron convencer a uno de sus clientes para usar contenedores como infraestructura de producción.  Al parecer el área de arquitectura de este cliente ya venía estudiando la posibilidad de usar contenedores a partir de la implementación de OpenShift. Finalmente los planetas se alinearon y allí estaré yo colaborando en el diseño e implementación del esquema de desarrollo y deployment sobre OpenShift.

OpenShift es el nombre de “una marca” creada por RedHat y que incluye:

  • OpenShift Origin, que es el proyecto de código abierto
  • OpenShift Online, que es una instancia de OpenShift administrada por RedHat, que corre en la nube y que se ofrece como servicio
  • OpenShift Enterprise, es que la plataforma que RedHat vende como producto para instalación on-premise

OpenShift está basado en Kubernetes (el orquestador de contenedores desarrollado por Google) y agrega a este una serie de servicios/funcionalidades complementarios que facilitan mucho su uso y administración.

A medida que vaya aprendiendo más de OpenShift, iré compartiendo más información.

Build de 10 minutos y categorización de tests

Cuando el equipo actual tomó a su cargo el sistema este tenía una alto grado de inestabilidad y prácticamente no tenía tests automatizados. Gradualmente se fueron agregando tests que ayudaron a mejorar a la estabilidad del sistema. En un punto se llegó a tener unos ~2600 tests de componentes/unitarios cuya ejecución excedía los 30 minutos. Todos estos tests eran ejecutados como parte del build de integración continua. A esto se sumaba el hecho de que equipo hacía feature-branches, los cuales también eran buildeados automáticamete, aumentando la carga del build server. Llegado un punto, cada vez que un developer hacía un commit (+push) tenía que esperar, en el mejor de los casos, unos 40 minutos para obtener feedback. Podía llevar a pasar que el build server estuviera ocupado y entonces el build quedaba encolado estirando aún más el tiempo de espera.

Ante esta situación hicimos dos cosas. En primer lugar instalamos un segundo agente del Build Server, para bajar el tiempo tiempo de espera en cola. En segundo lugar categorizamos los tests y ajustamos la configuración del build server. En este segundo punto quiero profundizar.

Es un práctica muy difundida y aceptaba, el tener un build de integración/feedback continua que no exceda los 10 minutos (algunas referencias para profundizar aquí y aquí). En línea con esto decidimos categorizar los ~2600+ tests, identificando aquellos que cubrían las partes críticas de la iteración. Identificamos unos ~600 tests fundamentales cuyo tiempo de ejecución resultó en unos 7 minutos. Categorizamos esos tests como “core”. Al mismo tiempo ajustamos el build server para que se ejecuten en forma continua (ante cada commit+push) los tests “core” y de los “current” (pertenecientes a la iteración actual), de manera de poder tener un feedback “rápido”. Por otro lado, creamos otra tarea que se ejecuta al fin del día para correr el set completo de tests.

 

Banca DevOps, nuevo proyecto

Desde hace un tiempo hay en Argentina un auge de transformación digital en el sector bancario, el cual suele incluir iniciativas Agile + DevOps. En ese contexto, fui contactado hace un par de semanas por un banco para colaborar en la optimización de su flujo de valor (en realidad el pedido vino por otro lado y después de un par de charlas derivó en esto).

Luego de un par de conversaciones con las personas que me convocaron, nos pusimos de acuerdo y accionamos. La idea es comenzar trabajando sobre un equipo en concreto, y luego incorporar gradualmente otros equipos. La intención es poder ir resolviendo problemas reales de los equipos y definir reglas/patrones a partir de generalizaciones de lo realizado en cada equipo.

Una de mis premisas de trabajo cuando participo de este tipo de iniciativas es definir criterios claros y objetivos de éxito. Muchas veces he visto iniciativas fundamentando su éxito en frases tales como “La gente se siente más contenta”, lo cual puede estar bien para “la gente”, pero muchas veces resulta insuficiente para quien paga. Tal vez sea una limitación mía, pero no he tenido éxito convenciendo gerentes con “sensaciones”. Tal vez sea por mi perfil ingenieril: las sensaciones me parecen importantes, pero a la hora de tomar desiciones quiero números concretos. En este sentido, en el contexto de esta nueva iniciativa, hemos definido dos métricas iniciales como referencia: lead time y risk exposure.

Continuará…

Un equipo con 5 Pinos

Hacía bastante tiempo que tenía ganas de trabajar con la gente de 10 Pines. Finalmente luego varios desencuentros de coordinación, hace un par de semanas @egutter me llamo y me dijo: “Tengo un proyecto para que trabajemos juntos”. Y así fue.

Hace un par de semanas comencé a trabajar con un equipo de 10 Pines. En realidad es un equipo mixto en el que hay gente de 10 Pines y también de otras empresas.

El proyecto en cuestión se trata de hacer mantenimiento evolutivo de una aplicación de gestión de contratos, facturación, etc, etc. La aplicación está construida con C#, ASP.NET MVC y NHibernate, corre sobre SQLServer e interactua con Biztalk. Como herramienta de gestión y repositorio de código se utiliza TFS y como servidor de integración continua, Team City.

Sin embargo, a pesar de estas cuestiones técnicas, yo no estoy ocupando un rol técnico en el proyecto. Me sumé al equipo en el rol de facilitador/gestor/experimentador. La idea es intentar mejorar la dinámica de trabajo del equipo.

Continuará…