Historia de un proyecto (no tan) ¿ágil?

En este momento estoy participando en dos proyectos, en uno tengo un rol técnico y en otro un rol más de gestión. A este segundo caso quiero referirme.

El objetivo de este proyecto es reemplazar una aplicación de escritorio con una aplicación web de manera que esta aplicación web ofrezca algunas funcionalidades adicionales. El equipo tiene varios developers y un tester. Yo me sumé al proyecto meses después del primer release (que llevó un 1 año) con el objetivo de intentar mejorar el flujo de trabajo ya que el equipo venia con algunos problemas de estimación, planificación y ejecución. Si bien el propio equipo decía estar trabajando “de forma ágil” en mi opinión no era así, pero a mi parecer esto no era un problema, ya que trabajar de forma ágil no lo veo como un fin en si mismo, sino como un medio para un fin. Desde la perspectiva del cliente el producto entregado estaba muy bien en términos de usabilidad, calidad, etc, pero el proyecto no estaba tan bien ya que el avance era lento y la fecha de fin de proyecto estaba retrasándose recurrentemente. El proyecto tenia una infrastructura de CI con muy pocos tests automatizados, pero con una importante cantidad de casos de pruebas de ejecución manual. El proceso de deployment estaba automatizado.

Lo primero que hice al sumarme al proyecto fue lo mismo de siempre: observar, preguntar y medir. Luego propuse algunos experimentos en la forma de estimar y planificar. A continuación propuse establecer una cadencia en el proceso de desarrollo, hasta ese momento el equipo hacía iteraciones de 10 días hábiles de desarrollo (coding y testing), lo cual hacía que los dias de review y planning cayeran en días variables. Ajustamos esto y establecimos los lunes (cada 2 semanas) como día de review+retro+planning. Todo esto ayudó a establecer un ritmo estable, predecible y facilitó la interacción con los usuarios. Estos cambios también fueron muy bienvenidos por el Product Owner. Antes cada cambio propuesto volvimos a medir para confirmar si se había producido una mejora concreta o no. La semana pasada acordamos establer una cadencia de release haciendo 1 release por mes.

Continuará…

Adivinanza: el proyecto con calidad

Advertencia: aunque el siguiente relato parezca ficción, doy mi palabra que es está basado en hechos reales.

Érase una vez una eṕoca en la que me toco trabjar en 2 proyectos en simultáneo. Pertenecian a organizaciones distintas. Ambos estaban construidos con la misma tecnología y ambos llevaban aproximadamente el mismo tiempo de desarrollo al momento que yo me sumé. Pero tenían algunas diferencias radicales.

A)
Un proyecto llevaba ya varios releases productivos y de hecho realizaba releases en forma frecuente. El otro proyecto tenía apenas un release que había ocurrido luego de casi 1 año de desarrollo.

B)
Un proyecto tenía pruebas automatizadas de distinto tipo que sumaban varios cientos: pruebas unitarias, de integración, de aceptación hasta incluso de performace. El otro proyecto no tenía más de 20 pruebas unitarias automatizadas, tenía muchos casos de prueba de ejecución manual pero que obviamente no se ejecutaban todo el tiempo.

C)
En un proyecto usaban trunk-based development y escribían todo el código haciendo pair-programming. En el otro proyecto usaban feature branches y merge-request/code-reviews.

D)
En un proyecto trabajaban a lo Extreme Programming. En el otro proyecto dicían hacer Scrum.

E)
En un proyecto el cliente estaba contento con los resultados y con la marcha del proyecto. En el otro proyecto el cliente no estaba contento con los resultado ni tampoco con como marchaba el proyecto.

En un proyecto me pidieron que los ayude a estabilizar el build y optimizar el tiempo que este tardaba en correr que solía rondar los 50 minutos. En el otro proyecto me pidieron dar una mano para mejorar la dinámica de trabjo en un sentido amplio.

Uno era el proyecto A y el otro era el proyecto B. Adivinen cual es cual.

Continuará…

DevOps: un camino bottom-up

Actualmente estoy trabajando en una institución bancaria colaborando entre otras cosas en una iniciativa DevOps. En forma resumida la iniciativa surgió a partir de varios equipos de desarrollo trabajando en paralelo de forma independiente. Cada equipo fue trazando “su propio camino a producción” con la colaboración de algunos miembros del equipo de infraestructura. Luego, por iniciativa de un gerente de desarrollo, representantes de cada equipo y algunos miembros del equipo infraestructura comenzaron a reunirse para compartir lo hecho por cada uno.

De esta forma, con un esquema de reuniones periódicas, vamos generando acuerdos a partir de las experiencias concretas de cada equipo. Las primeras reuniones fueron un poco caóticas, pero gradualmente van mejorando y agregando más valor. 

A mi parece el uso de un enfoque bottom-up en una institución bancaria es algo novedoso porque tradicionalmente este tipo de organización tienen más a los enfoques top-down. En dicho enfoques top-down hay generalmente un equipo/grupo/gerencia que define/diseña/toma decisiones y luego baja linea al resto de la organización imponiendo dinámicas y políticas que suelen no convencer a la gente que concretamente hace el trabajo de desarrollo/operación.

En los enfoques bottom-up como el que menciono aquí, el trabajo suele ser más lento pero a mi parecer más efectivo ya que se le da voz a los equipos y se construye a partir de su experiencias.

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.