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.

Anuncios

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á…

Historia de una primera salida a producción

Finalmente luego de 9 iteraciones(~4 meses) llegamos a producción. Mmmm, no, en realidad fue casi un año de trabajo. El proyecto comenzó con un sistema legacy desarrollado en Asia durante 6 años [1]. Sobre dicha plataforma hicimos una reingeniería para reemplazar algunos módulos y agregar uno totalmente nuevo. En ese contexto se comenzó a trabajar con un equipo de 4 personas que fue creciendo a lo largo del año hasta llegar a ser más de 25 personas (yo me sumé cuando rondábamos las 10).

A medida que la cantidad de personas se fue incrementando fuimos partiendo el proyecto/equipo en sub-proyectos/sub-equipos hasta llegar a ser 5 sub-equipos/sub-proyectos [2].

En Enero tuvimos el release del primer módulo que reconstruimos de cero [3]. En Mayo fue el release del segundo módulo y finalmente el viernes pasado tuvimos el release de 3 módulos más. Los primeros dos módulos había sido producto del trabajo de 2 sub-equipos, mientras que los módulos liberados el pasado viernes fueron resultado del trabajo del “big-team”, o sea, el release incluyó productos de todos los sub-equipos.

En este año de trabajo he compartido experiencias muy enriquecedoras con un excelente grupo de trabajo. Siendo alrededor de 30 personas, hubo algunos con los que compartí muchas situaciones y otros con los que apenas hablé. Entre todas las cuestiones acontecidas durante este año me parece importante destacar:

  • El foco en la mejora
  • El espíritu colaborativo
  • La especial atención a las personas
  • La disciplina en la forma de trabajo
  • El manejo de los esfuerzo extraordinarios (horas extra)
  • El manejo de las situaciones “no tan felices”

[1] En el artículo Aplicaciones legacy, monolitos y microservicios escribí más detalladamente sobre esta situación.

[2] En el artículo team.split() & project.new(), conté sobre la creación de uno de los sub-equipos/sub-proyectos

[3] En el artículo projifm, estadísticas del primer release compartí algunas estadísticas de ese primer release.

Estabilizando la velocidad

Durante las dos primeras iteraciones decidimos no puntuar las stories con un valor explícito de estimación. Simplemente a la hora de determinar el compromiso de la iteración utilizamos la tantas veces usada técnica de “estimación a ojo de buen cubero”. Pero ya en la tercera iteración el cliente nos pidió que puntuáramos las todas las stories del backlog para poder hacer una proyección. Así que eso hicimos, repasamos todo el backlog haciendo una estimación de mano (una variante del famoso planning pocker).

Adicionalmente al comienzo de cada iteración, repasamos los valores asignados a cada story  y de considerarlo necesario los volvimos a estimar.

La semana pasada completamos la sexta iteración y por primera vez entregamos exactamente lo que habíamos comprometido. Hasta entonces siempre habíamos tenido un pequeño delta positivo o negativo.

Comprometido vs. Entregado

Como se puede apreciar en el gráfico precedente la cantidad de puntos entregados por el equipo ha ido en aumento desde la iteración 4. Parte de ese incremento se debe a que las iteraciones 4 y 5 tuvieron días feriados en los que no trabajamos y que hicieron que dichas iteraciones fueran más cortas en términos de días trabajados.

En este momento estamos trabajando en la iteración 7 y el tamaño del compromiso tomado es bastante mayor a las iteraciones anteriores (75 puntos). Esto se debe a que se sumo una nueva persona al equipo.

Al finalizar la iteración 8 saldremos a producción. Yo hubiera preferido salir antes, pero resulta que estamos reemplazando un producto existente y ha sido muy difícil hacer un recorte de funcionalidad que nos permita salir antes sin impactar negativamente en el negocio.

Continuará…

Mejorando el flujo de trabajo a partir del burndown chart

Ayer completamos la tercera iteración del proyecto y la cosa empieza a fluir de lo lindo. Si bien veníamos cumpliendo con los compromisos asumidos el flujo de trabajo en las dos iteraciones anteriores había sido medio accidentado/abrupto como evidencia el burndown chart de la iteración 2.

Burndown chart iteración 2

En la retrospectiva de la iteración 2 tomamos conciencia de este flujo accidentado y decimos tomar medidas para mejorarlo. Principalmente intentamos tener ítems de backlog más pequeños, limitar el WIP y deployar de forma más frecuente. El resultado se puede apreciar en el siguiente gráfico.

Burndown chart iteración 3

 

A pesar de la mejora yo sigo teniendo un pequeña molestia pues no me gusta el cierre abrupto de la iteración. Este cierre es consecuencia de que terminamos a último momento el testing de la última porción de trabajo.

Ya que he compartido los gráficos quiero aprovechar también para compartir un breve análisis comparativo de los mismos:

  • Si bien ambas iteraciones tuvieron la misma duración calendario, la cantidad de días laborales en cada una, fue diferente (los días no laborales está representados por las franjas verticales de color gris más oscuro).
  • Debido al ítem anterior, el tamaño del compromiso asumido por el equipo también fue distinto: en la iteración 2 el compromiso fue de más de 50 puntos, mientras que en la iteración 3 fue de unos 40 puntos.