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.

Cierre de cuatrimestre a puro TDD (algo3, 1c-2012)

Y se fué uno más, pero distinto y para bien. En líneas generales mantuvimos la misma modalidad que los cuatrimestres anteriores, pero creo que en esta ocasión hemos manejado mejor los tiempos y hemos resultado “más convincentes” en algunas cuestiones.

Entre los cambios del curso Jueves-tarde sumamos un nuevo colaborador docente: Diego Marcet, graduado de la casa, ex-alumno de la materia y ex-compañero mio de trabajo en Southworks.

Otro de los cambios implementados fue el uso del campus virtual (basado en Moodle) para la publicación del material de estudio. Yo personalmente fuí un poco más allá y lo utilicé para manejar la interacción con mis grupos vía los foros. La ventaja que le veo al uso de foros tiene que ver con que la resulta muy cómodo visualizar el hilo completo de la conversación.

A mi parecer la particularidad más destacada (al menos de nuestro curso) fue el fuerte incampié que hicimos en el uso de TDD, lo cual dió sus frutos en el trabajo final, donde varios alumnos desarrollaron gran parte de trabajo usando esta técnica.  Es más, la cantidad de pruebas unitarias de los TP finales fue record en el caso de los TPs que yo corregí: me entregaron TPs con más de 200 pruebas unitarias, llegando a niveles de cobertura llegando al 80%.

La última innovación a mencionar es la práctica de integración contínua. Si bien este tema lo vemos en la teoría desde hace varios cuatrimestres, este año fui más allá y levante un servidor de integración contínua para mis alumnos (lamentablemente no tenía una gran infraestructura, asi que solo lo pude hacer para los 3 grupos a mi cargo). El proceso de build incluyó: compilación, ejecución de pruebas y medición de cobertura.

Si bien no hicimos la dinámica de retrospectiva global, yo hice una más reducida con los alumnos de mis grupos y el feedback fué muy positivo: solo surgieron algunas cosas menores para mejorar que comentaré en un próximo post.

Team City organizational setup alternatives

The way we decided to manage the continuous integration process is to have one build server per project, that is an exclusive virtual machine with a Team City install running on it. These strategy gives each team full control over the server without having to worry about other projects.

Other alternative, that I think is more frequently used, is to have only one build server for the whole organization and several build agents. When using this strategy the build server concentrate the all build configurations, checkouts the code and delegate to an agent the execution of the build steps. If you have two projects with incompatible software requirements (i.e. one project running on Windows and other on Linux), then you could setup one Windows agent and Linux agent.

Last week I setup an environment following this second alternative. I took 2 machines, in the first one I installed a full TeamCity environment: server and agent, and in the second one I installed just an agent. It was very straight forward. One additional benefit of this setup is that it allows run builds in parallel.

Retrospectiva del tutorial de integración contínua

Hoy dí el tutorial de integración contínua que anuncié hace un par de dias.

Como de costumbre comencé con una dinámica para romper el hielo y conocer el perfil de los asistentes. Resulto que todos estaban familiarizados con la práctica de integración contínua pero no todos las utilizaban. De la gran mayoría de la sí la utilizaba una una interesante porción no había realizado el setup del del ambiente de integración, sino que utilizaban un ambiente que alguién más en su organización había configurado.

Luego de la apertura, la sesión transitó guiada por esta presentación que armé para la ocasión. Sinceramente la presentación no fué tan interactiva como me hubiera gustado, pero que estoy contento con el resultado: pudé contar todo lo que habia planeado (e incluso algunas cosillas más), hubo espacio que los asistentes hicieran sus aportes y también para contestar consultas. Nadie se animó a trabajar a la par mia e ir configurando su propio ambiente, pero creo que en parte fue porque mi forma de encarar la sesión no fue lo suficientemente motivadora para ello. Definitivamente este es un punto a mejorar.Adicionalmente a lo expuesto en el material de la presentación, hablamos sobre algunas cuestiones conceptuales y también sobre algunas herramientas adicionales: Sonar, Janky and CloudBees.

Finalmente para cerrar pedí feedback con la técnica de las carita:

  • 🙂  18
  • 😐  0
  • 😦  0

(hay que considerar que unas 4 personas de fueron antes de que terminara la actividad)

Evento: Tutorial de Integración Contínua

El próximo miercoles a las  18.30 hs. voy a dar un tutorial de integración contínua en el contexto de los encuentros mensuales del grupo Agiles @ Buenos Aires.
La entrada es libre y gratuita, pero requiere registración previa. Los interesados pueden registrarse via Meetp up
A grandes rasgos la idea del tutorial es repasar los fundamentos que sustentan esta práctica y analizar distintas alternativas técnológicas para su implementación en los distintos lenguajes. Al mismo tiempo pondremos manos a la obra automatizando el build de algunos proyectos y resolviendo los problemas más comunes que suelen aparecer. Aquellos participantes que lo deseen pueden traer sus propias máquinas para trabajar y automatizar sus propios proyectos.

Build Servers Initiative

A couple of weeks ago I started helping some teams to set up their continuous integration servers. There are several tools and strategies you can use to accomplish this task. In our case, we decided to use MSBuild as the automation tool and TeamCity as the continuous integration server. Team City provides several features to automate the build process, but we preferred to minimize the dependencies with Team City for 2 main reasons:
  • We want to be able to run the automated build process in the devs machines.
  • We want to be able to use another build server.
For us, the standard build process includes:
  • Running source analysis (StyleCop)
  • Running code analysis (FxCop)
  • Compiling (CS compiler)
  • Running tests (MSTest)
  • Running coverage (VS build-it coverage feature)
MSBuild only provides built-in support to compile, so for the rest of these tasks we had to do some research. A couple of weeks ago Gabi Iglesias posted about some of the spikes we did.
After research and spiking, this is the approach we finally took:
  • To run StyleCop and FxCop we are using MSBuild Extension Pack, an open source project published at CodePlex
  • To run MSTest and coverage we are using home made MSBuild tasks developed by our Engineering Excellence team (these tasks were developed back in 2008, so for our new initiative we had to update them)
In upcoming posts we will provide more details on this topic.