Notas del Meetup sobre Patrones de Infraestructura para Continuous Delivery

Si bien había más de 100 inscriptos la cantidad de participantes fue alrededor de 30, lo cual es está dentro de los parámetros esperados para los Meetup gratuitos de Agiles@Baires. La mayoría de los asistentes eran desarrolladores (~80%) y el resto se repartía entre gente de operaciones/sysadmins y gente de gestión. La audiencia estuvo muy participativa, hubo varias consultas e incluso algunos participantes hicieron aportes desde su propia experiencia.

A mi gusto la sesión fluyó muy bien, sobre todo considerando que fue la primera vez que la hice. Fueron alrededor de 80 minutos de exposición, con algunas preguntas intercaladas, y otros 20 minutos dedicados exclusivamente a consultas. De cara a la presentación en Agile, voy a tener que hacer varios ajustes y practicar un poco más, ya que el límite de tiempo que tengo es de 75 minutos y al mismo tiempo al ser una sesión en inglés es posible que no tenga tanta soltura en la oratoria.

Agradezco a todos los participantes por el feedback y les dejo aquí los slides utilizados.

 

Meetup Agiles@BAires: Infrastructure Patterns for Continuous Delivery

El próximo jueves 20 de Julio en el Meetup de Agiles Argentina estaré dando esta sesión. El título está en inglés porque la sesión la preparé originalmente para darla en la conferencia Agile 2017 y darla ahora en Buenos Aires me sirve en cierto modo como un ensayo.

Comparto algunos datos de esta sesión que pueden resultar de interés para la audiencia:

  • Formato: charla tradicional, basada en diapositivas, condimentada con algunas actividades interactivas.
  • Duración: ~80 minutos
  • Audiencia: gente de perfil técnico sin ningún conocimiento previo en particular
  • Palabras clave: continuous-delivery, devops, automation, infrastructure as code

La sesión está estructurada en 2 bloques:

  • un primer bloque introductorio donde repasamos algunos conceptos básicos de continuous delivery/devops
  • un segundo bloque dedicado a presentación de diversos patrones entre los que se incluyen: incremental environments, automation layers, multi-versioning y split pipeline entre otros.

La cita es en la Facultad de Ingeniería de la UBA (Paseo Colón 850), en el aula 403 a partir de las 19 horas (puntual). Obviamente es totalmente gratis pero por favor los interesados registrarse en la página del Meetup.

Mis sesiones en Agile 2017

En agosto estaré participando por primera vez en la conferencia Agile donde estaré presentando dos sesiones:

Ambas sesiones están inspiradas en las experiencias y lecciones aprendidas que he recolectado en los últimos años. Ambas sesiones son en formato presentación con una duración de 75 minutos (con espacio de preguntas incluido).

A modo de ensayo, estaré dando la segunda de estas sesiones el próximo Jueves 20 de Julio en el contexto del Meetup de Ágiles Argentina. La cita es en la Facultad de Ingeniería de la UBA a las 19 horas (aula a confirmar).

Taller de Continuous Delivery

Por estos días me encuentro trabajando en la preparación de un Taller sobre Continuous Delivery. El taller surgió a partir del pedido concreto de un cliente, pero obviamente armar un curso para dictarlo solo una vez no es negocio, así que seguramente agende para volver a dictarlo en un futuro (interesados contactarme ;-)).

El taller es de índole de práctica, o sea los participantes ponen manos en la masa. Para ello he preparado una imagen de máquina virtual para que los alumnos hagan los ejercicios. Hay algunos ejercicios de carácter más teórico (por ejemplo diseño de ambientes) pero la mayoría son de índole práctica orientados a herramientas (por ejemplo configurar Jenkins para hacer deploy automatizado de una aplicación en diversos ambientes).

Comparto aquí un video con un poco más de información.

Versionado de base de datos

Este es un tema que curiosamente para mi muchos equipos no tienen incorporado como práctica. A mi parecer en la actualidad la estrategia más común para esto es lo que desde hace años comenzó a hacer Ruby on Rails:

  • escribir los scripts incrementales de actualización de la base siguiendo una convención de naming incremental (números secuenciales o timestamp invertidos). Estos scripts al ser texto plano se pueden almacenar naturalmente en el repositorio de código junto al código de la aplicación
  • por otro lado se agrega una tabla en la propia base de datos para llevar registro de los scripts aplicados lo cual determina la versión de la base de datos.

En el caso de Ruby on Rails, uno debe encargarse de escribir los scripts (para escribir los puede usar un DSL en lugar de sql) y luego el propio framework brinda funcionalidades para crear la tabla de versión, ejecutar los scripts y llevar control de su ejecución. No estoy seguro si Rails fue el primer framework en implementar esta estrategia pero en la actualidad existen diversas herramientas en distintos lenguajes que la implementan como ser: FluentMigrator (con foco en C#), LiquidBase (con foco en Java/Grails).

Una herramienta que implementa esta estrategia y con la que he estado trabajando este último tiempo es Flyway, les comparto un video que muestra su uso y explica algunos detalles.

Entrega continua principio #1: 3 repositorios por aplicación

Creo que en la actualidad está ya claro que debemos tener un repositorio para versionar el código de nuestra aplicación. Algunos también versionan  en ese mismo repositorio la configuración de la aplicación. Para algunos casos esto puede ser suficiente, pero en contextos de entrega continua no me parece apropiado.

En primer lugar la configuración y el código tienen un tasa de cambio distinta, el código cambia mucho más rápido que la configuración. Al mismo tiempo la configuración suele variar dependiendo del ambiente en que se despliegue la aplicación. Finalmente, dependendiendo de la organización puede que la configuración del ambiente productivo sea reservada y sólo algunos miembros de la organización puedan accederla. La propuesta entonces es tener un repositorio exclusivo para almacenar la configuración de la aplicación. En particular, yo suelo crear en ese repositorio un branch por cada ambiente. Adicionalmente para facilitar el trabajo del equipo de desarrollo suelo almacenar junto al código, la configuración del ambiente desarrollo.

Finalmente necesitamos un tercer repositorio para almacenar los scripts de despliegue. La idea de poner estos scripts en un repositorio exclusivo tiene que ver otra vez con su tasa de cambio esporádica y también con el hecho de que es posible que estos scripts sean creados/manipulados por personas distintas a las que escriben el código, típicamente sysadmins.

En algunos casos particulares puede que sea necesario un cuarto repositorio, por ejemplo si uno quisiera generar modulos Puppet para automatizar el provisioning de la aplicación.

Pensándolo bien, creo que el título del artículo no es preciso, el principio es versionar todo,  el hecho de usar 3 repositorios es más bien una forma de implementarlo, que puede no aplicar siempre.

Nuevo proyecto de CI / CD

Hacía fines de diciembre del año pasado me contactaron de una empresa para que los ayudara con una iniciativa de Integración Continua. Intercambiamos un par de mails, tuvimos una llamada telefónica de 20 minutos y acordamos una primera reunión.

Desde mi punto de vista la práctica de integración continua no es un fin en sí mismo sino que es una herramienta. Por ello, una de las primeras cosas que pregunté fue: ¿Cuál es su problema? ¿Qué esperan solucionar con esta práctica? La respuesta fue clara, había dos problemas principales: por un lado la calidad del producto y por otro el desperdicio de tiempo invertido en el despliegue de la aplicación a los distintos ambientes. Esto me permitió entender que la cuestión iba bastante más allá de la integración continua.

El desafió me pareció muy interesante, pues se trataba de una empresa grande, con equipos distribuidos geográficamente en distintos lugares de latinoamérica y cuyo negocio estaba centrado en la venta de soluciones de banca. La empresa contaba con un plataforma de productos que vendía a distintos clientes y cada venta implicaba una implementación/customización de los productos. De esta forma había equipos trabajando sobre los productos y en paralelo un equipo de implementación para cada cliente que compraba el producto.

En términos de administración de la configuración a primera vista la naturaleza del negocio llevaba a tener un trunk de producto con un branch por cada cliente. Fácil decirlo, no tan fácil de implementarlo sobre todo teniendo el código de todos los productos en un único repositorio CVS.

La plataforma tecnológica era Java, un clásico en sistemas de banca. Pero dado que la solución se vendía a distintos clientes la aplicación debía funcionar sobre distintos ecosistemas tanto a nivel base de datos, application server y service bus.

Un último condimento no menor es que gran parte del código venía arrastrándose desde hacía varios años y tenía dependencia con componentes open source ya sin soporte (por ejemplo Apache Hivemind). Adicionalmente también se estaban usando versiones viejas de algunas herramientas (por ejemplo java6  y maven2).

Cabe destacar que varias de este cuestiones no las sabia inicialmente, sino que las fui descubriendo una vez empecé a trabajar.

La situación era compleja y las expectativas del cliente eran muy grandes. Mi propuesta fue simple y concreta:

Busca un equipo que esté interesado en trabajar en esta iniciativa. Yo me siento y trabajo con el equipo codo a codo 1 mes para resolver los impedimentos que el equipo considere le impiden construir software de calidad.

Al cliente, le gustó la propuesta y la bola empezó a rodar.

Continuará…