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

Continuous: Integration vs Delivery vs Deployment

En los últimos dos años he repetido incontables veces la diferencia entre estas tres prácticas y dado que no encontré ninguna explicación online que me satisfaciera, he decidido escribir mi propia explicación.

Continuous Integration: el software suele desarrollarse en equipo, donde cada miembro trabaja en su máquina en una porción del software. En ese contexto, la práctica de Continuous Integration propone integrar de forma continua el trabajo realizado por cada miembro del equipo. Esto implica una serie de cuestiones como ser el uso de controlador de versiones y contar con un ambiente de integración donde puedan ejecutarse verificaciones sobre software integrado.

Continuous Delivery: en términos organizacionales esta práctica es poner en manos del negocio la decisión de cuándo ir a producción. Más concretamente eso implica que cada build exitoso pueda (si el negocio así lo decide) ir a producción. entiéndasee build como el artefacto resultante del proceso de integración)

Continuous Deployment: está práctica va más allá de Continuous Delivery e implica que cada build exitoso va automáticamente a producción. Tal como propone Jez Humble, un mejor nombre para esta práctica sería Continuous Release. Continuous Deployment implica Continuous Delivery pero no al reves.

Estas tres prácticas tienen un aspecto técnico relacionado a herramientas y aspecto humano relacionado a hábitos y reglas que las personas deben incorporar y que personalmente considero que es el mayor desafío a la hora de intentar implementar estas prácticas. Ejemplo: de nada sirve tener un controlador de versiones si los miembros del equipo hacen commit una vez por día.

El orden en que describí cada práctica tiene que ver con el orden natural de adopción de las misma. Cabe aclarar cada práctica puede implementarse con distintos “niveles de profundidad” los cuales dependerán del contexto de cada proyecto/organización.

Muchas veces al explicar estas prácticas la audiencia tiende a decir que quiere implementar Continuous Delivery ante lo cual suelo aclarar: “No todas las prácticas son necesarias para todo contexto” y a continuación pregunto: “¿Su negocio realmente necesita continuous delivery?” En determinados contextos tener Continuous Delivery puede ser imprescindible para que el negocio sea competitivo, mientras en otros contextos (posiblemente más estables a nivel de negocio), sea simplemente un nice-to-have.

Como comentaba un amigo que trabaja en la industria petrolera: “Nosotros tenemos 3 releases anuales planificados e inamovibles”, en un contexto así posiblemente no se justifique el esfuerzo que implica adoptar continuous delivery. Distinto es el caso de un negocio muy variable que requiere de cambios constantes en sus aplicaciones donde no tener Continuous Delivery podría implicar perder el negocio.

Por su parte la práctica de Continuous Integration tiene algunas particularidades respecto de las otras dos prácticas. En primer lugar, es una práctica higiénica, lo cual implica que en términos generales siempre debe utilizarse. En segundo lugar es una práctica “a puertas cerradas” en el sentido que su uso está complementamente en manos del equipo de desarrollo. No es necesario aprobación y/o interacción con personas de otras áreas de las organización ni con el usuario. Si bien puede ser útil tener ayuda del grupo de infraestructura para montar un servidor de integración continua, la realidad es que no es algo imprescindible, el propio equipo puede montar un servidor de integración continua en la máquina de alguno de los miembros del equipo o bien podría utilizar algún servicio online (como Travis o CloudBees).

Para quienes quieran profundizar les recomiendo es artículo de Jez Humble: Continuous Delivery vs. Continuous Deployment.

Para cerrar les comparto un par de imagenes (de mi autoría) que esquematiza la diferencia/relación entre estas prácticas.

ci_y_cd

 

cd_y_cd

Build Tools for .NET

Setting up a build server for .NET development is not so easy like in Java. We could find several explanations for this and one of them could be the huge dependency .net developers have with Visual Studio. I have met many developer that have no idea of how to generate a build of their application without using Visual Studio. Even more, it is very common to find people installing Visual Studio in their build servers 😦 (I did that several times!). Maybe because of this, command line tools never had much popularity among .NET developers. At the same time, Visual Studio along could be not enough to create a quality build (Visual Studio out of the box can not run NUnit tests and StyleCop analysis).

My approach to build my applications is to use a build tool. For the case of .NET there a couple of build tools out there. I think the most popular are:

  • NAnt: it is basically a port of Ant, the famous build tool for Java
  • MSBuild: the Microsoft proposal
  • PSake: is a relatively new tool based on Power Shell

In my case, I choose MSBuild, but it is not enough, because this tool does not have out of box support for integration with some other tools that I use like Nunit, StyleCop, JsLint.  So  in additional to MSBuild I use a set of community extensions called MSBuild Community Tasks.

But the story does not end here, when I want to setup a new build server (or when a new member joins my team) several stuff must be installed in a new box. To simplify this setup, I have created an installation package that contains all the tools I commonly use to build my applications. I have called this package BuildTools4Net. Its current version includes the following items:

  • MsBuildCommunity Taks
  • NUnit
  • SharptLinter
  • FluentMigrator
  • StyleCop

Because of licensing concerns I can not share the my BuildTools4Net installation package, but I am working on script some you can create your own installations package.

Resultados del Taller de lntegración Continua

El jueves pasado hicimos en Kleer el taller de integración contínua. No tuvo tanta práctica como yo esperaba, pues hubo muchas consultas, pero creo que estuvo muy bien. Cubrimos todos los puntos del programa y atendimos a todas consultas de los asistentes.

Algunas variantes a considerar para futuras ediciones:

  • Enfocar el taller sólamente en Jenkins
  • Enfocar el taller en una única tecnología (Java , .Net, etc)
  • Hacer el taller de día completo o de dos medios días para poder hacer más práctica

Les dejo algunos frases de las encuestas de la evaluación completadas por los asistentes:

  • “Excelente las explicaciones y conocimientos expuestos”
  • “Muy bueno, si bien conocía algunas de las herramientas, vi un poco más en detalle todo el potencial de uso que tienen”
  • “Nada para agregar, el taller fue genial..”
  • “Excelente Didáctica y cobertura del tema”

Screencast sobre despliegue automático en .NET

El jueves pasado participé de un Meet up organizado por Microsoft Argentina en el cual presenté la estrategia de despliegue automático que estoy usando en uno de mis proyectos actuales.Como la sesión no fue grabada, grabé este screencast.

Para aquellos interesados en profundizar en este tema, les recomiendo que se sumen al taller de integración continua que voy a dictar a comienzos de diciembre.

cd_en_net

Continuous Delivery en FIUBA

La semana pasada asistí a la presentación del trabajo profesional de Hernán Carrizo.

El trabajo consistió en la implementación de un pipeline de continuous delivery en un proyecto existente. Tomé algunas notas interesantes, de directa aplicación en mi actividad profesional actual. Pero sin duda lo mejor de todo es ver que en Fiuba se hacen trabajos sobre temáticas actuales e incluso innovadoras en un punto.

Algo que me llamó la atención fue una de las preguntas de apertura de la presentación:  ¿Cuanto tiempo lleva poner en producción el cambio de una línea de código?

La presentación y el trabajo en general me resultaron muy interesantes, lo cual no me extraña considerando quienes fueron los directores del trabajo: Carlos Fontela y Juan Gabardini, Say no more.

Jenkins: Plugins infaltables

De cara a automatizar parte de la corrección de los trabajos de los alumnos de la materia que dicto en UNQ, ayer estuve configurando un Jenkins. La idea es que los alumnos entreguen sus trabajos via Github, o sea, cada alumno tendrá un repositorio en GitHub. Llegada la fecha de entrega de cada trabajo, el build server (Jenkins en este caso) descaga los repositorios y verifica que existan archivos correspondientes a la entrega.

Como parte de la configuración de este Jenkins, instalé los siguientes plugins que me parecen fundamentales:

  • Git: la función de este plugin es obvia, permite a Jenkins conectarse con repositorios Git
  • Green Balls: por defecto, Jenkins representa el estado “build exitoso” con el ícono de una pelotita azul. Este plugin cambia dicha pelotita azul por una pelotita verde.
  • Copy Artifact: permite copiar artefactos de un proyecto a otro
  • Email Ext: extiende la funcionalidad de notificaciones de email provista por nativamente por Jenkins

Anteriormente había comentado sobre un plugin para enviar notificaciones via Jabber (particularmente gtalk), en esta ocasión no lo instalé, pues creo que dicho plugin resulta útil para cuando uno trabajar en desarrollo y este no es el caso.