Jenkins: Jobs as Code

Jenkins: Jobs as Code

Una de las funcionalidades destacadas en la nueva versión de Jenkins es la posibilidad de definir los pipelines utilizando un lenguaje de dominio específico. Esto resulta muy útil cuando uno tiene que manejar una cantidad importante de jobs y al mismo tiempo facilita el control de configuración ya que permite que la definición de los jobs sea tratada como código en lo referente al almacenamiento y versionado.

Esta posibilidad de manejar los jobs como código es algo que está ahora más presente en Jenkins 2, pero la realidad es que es una funcionalidad que ya estaba disponible para las versiones anteriores de Jenkins mediante el uso de plugins y algunas otras herramientas.

En particular yo venia utilizando el Jenkins Job Builder, una herramienta de la gente de Open Stack que permite definir jobs en un archivo .yml, definiendo también relaciones «de herencia» entre los jobs. El Job build es básicamente un script python que parsea los .yml y utiliza la api de Jenkins para crear los jobs correspondientes.

Otra herramienta que provee una experiencia similar es el Job DSL Plugin. Este plugin provee la posibilidad de definir Job utilizando un DSL Groovy para la definición de Jobs. La forma de uso es: poner los scripts de definición de jobs en un repo y luego crear un job en Jenkins (típicamente llamado Seed) que monitorea el repo de scripts y que cuando detecta cambios ejecuta los scripts los cuales generan los jobs que hayamos definido.

Otras herramientas similares pero que no he probado lo suficiente son: el Build Flow Plugin y el Workflow plugin.

El camino freelance, parte 5: dos prácticas de gestión

El camino freelance, parte 5: dos prácticas de gestión

Cuando uno es contratado para un trabajo es de esperar que uno realice su trabajo de forma correcta, o sea: si me contratan para programar entonces debería programar bien (además de asegurarme de estar programando lo que el cliente espera), pero más allá de eso creo que hay otra serie de cuestiones importantes particularmente cuando uno trabaja en un esquema time & materials. Entre todas esas cuestiones hay dos que aplico siempre porque me ayudan mucho en la ejecución de mis proyectos.

Visibilidad continua

Dado que el cliente estará pagando por el tiempo que nosotros dedicaremos al trabajo me parece una obligación dar visibilidad de las cosas que hacemos. Y cuando hablo de visibilidad no me refiero a un mail semanal con un resumen de lo que hice en las pasadas 40 horas. En algunos contextos eso puede estar bien, pero yo prefiero trabajar con una visibilidad más granular para así permitir a mi cliente accionar y corregir el plan de acción en caso de ser necesario. En ese sentido yo suelo reportar a nivel diario. Básicamente informo todos los días: que hice, en que estado está, y que voy a hacer a continuación.
Comparto aquí uno de mis mails de proyecto mostrando este tema de la visibilidad.

Hi guys,

Today I completed the OAuth integration (story#7533). Unless you have a different opinion I will move it live today 5 PM (EST).

Next Steps: I will continue with story#7536 that was reported today as urgent.

Regards,
NicoPaez

Acción por defecto

Si bien siempre es bueno tener el OK del cliente antes de avanzar con una tarea, no todos los clientes responden rápidamente lo cual puede ocasionar que uno quede bloqueado, cruzado de brazos por horas o incluso días.  Si me quedo cruzado de brazos si cobrar ese tiempo, pierdo plata, pero si lo cobro el que pierde plata es mi cliente, lo cual a largo plazo también también me perjudica a mi. Para evitar esto lo que suelo hacer es pedir validación y proponer una acción defecto en un determinado tiempo límite.

 Hola Ale,

Te cuento que ya tenemos todo el código y datos listos para correr las pruebas de stress (ticket#362) y estaríamos en condiciones de comenzar con su ejecución mañana mismo.

Tal como hablamos la semana pasada, para ejecutar estas pruebas necesitamos una cuenta en ABCDE. En teoría la cuenta iba a estar disponible el lunes, pero aún no lo está. Entonces si la cuenta no está para mañana lo que haremos de cara a evitar retrasos en el proyecto es correr las pruebas con mi propia cuenta y luego arreglamos entre nosotros el pago.

Saludos,
NicoPaez

Me parece importante destacar que estas prácticas pueden resultar útiles en muchísimos contextos distintos, pero creo que cobran mayor relevancia en el caso particular de contratos time&materials.

Fin de proyecto

Fin de proyecto

Luego de 3 intensos meses esta semana terminé mi segundo proyecto inmersivo del año.  Me sumé al equipo para dar una mano con cuestiones de arquitectura y operaciones, pero como de costumbre, al trabajar inmersivamente con el equipo uno siempre termina en medio en otras cuestiones. En estos tres meses además de completar diversas funcionalidades también hicimos lo siguiente:

  • Corrimos pruebas de performance y en base a ellas hicimos diversos ajustes en la aplicación.
  • Diseñamos e implementamos una infraestructura escalable basada en AWS
  • Implementamos un proceso de despliegue automatizado basado en CodeDeploy
  • Instrumentamos la aplicación para posibilitar su monitoreo con New Relic y CloudWatch
  • Pasamos de un esquema de trabajo basado en iteraciones de 2 semanas a un esquema de entrega continua liberando funcionalidad tan pronto como se completa

En verdad disfrute mucho ser parte del equipo y estoy muy conforme con el trabajo realizado.

 

El tercero de la trilogía: Ensayos ágiles

En el primer libro contamos experimentos, casos de aplicación, experiencias del uso de métodos ágiles en diversos contexto.

En el segundo libro fuimos más allá presentamos técnicas, generalizaciones surgidas a partir de las experiencias vividas.

Mi idea para el tercer libro es reunir ensayos: reflexiones, cuestionamientos, críticas, desafíos al estado del arte y a los estándares preestablecidos.

Veo en esta serie de libros una evolución similar a la propuesta por el modelo Shu-Ha-Ri, siento este tercer libro el correspondiente al nivel Ri.

No se cuantos me seguirán en la iniciativa, pero lo voy planteando con bastante antelación pues me parece que esta propuesta puede llegar a requerir bastante más tiempo de trabajo que las anteriores.

ensayos_agiles

Delivery Pipeline con Jenkins 2

Si bien vengo trabajando con Jenkins2 desde que se publicó el release candidate, no había echado mano a la nueva funcionalidad nativa de pipelines. Sinceramente la miré por arriba apenas instalé Jenkins2, no me convenció y decidí seguir con la combinación de plugins que venia usando con Jenkins 1.6.

El lunes pasado me actualicé a Jenkins 2.8 y decidí investigar más en profundidad la funcionalidad de pipelines nativos.  Finalmente esta mañana logré completar una primera versión de mi pipeline utilizando el nuevo soporte nativo. Al hacerlo descubrí un montón de cosas interesantes que pueden llegar a disminuir considerablemente el costo de control de configuración de Jenkins (principalmente las cuestiones versionado, actualización y backups de jobs)

jenkins2-pipeline

 

XPConf 2016: algunas cosas para importar en Latam

Quiero compartir algunas actividades que viví en la conferencia y que podría resultar interesante tenerlas presentes para la conferencia latinoamericana Agiles.

Cena previa: la noche previa al inicio de la conferencia los organizadores realizaron reservas en diversos restaurantes cercanos al centro de conferencias para que los asistentes fueran a cenar en grupo con la intención de conocer a otros participantes. Cada uno debía pagar su cena, pero el hecho de que la organización hubiera hecho las reservas posibilitó que los lugares estuvieran preparados para atender mesas de 10 comensales.

Catering continuo: durante los 3 días que duró la conferencia hubo catering continuo, o sea, uno podia salir en medio de una sesión y ponerse a comer, no hacía falta esperar al break. Había breaks de 30 minutos a horarios predeterminados, pero el catering no estaba limitado a esos breaks, sino que estaba todo el día. Al mismo tiempo el catering estaba organizado en 4 espacios:

  • 1 espacio donde se servia café, té, agua y dulces
  • 3 espacios donde se servia comida salada que incluía: hamburguesas de distinto tipo, papas fritas, tartas, pizza, arroz, woks y pastas entre otros

Actividades «before office»: todas las mañanas antes de desayuno (7 AM) había sesiones de yoga, running y lean coffee.

Actividades «after office»: todos los días luego de la conferencia había actividades de networking: una degustación de whisky, juegos con premios de los sponsors, fiesta en el castillo, etc.

Open Space en paralelo: el market place del open space junto con la primera tanda de sesiones se hizo en el «after office» del primer día. Luego, el resto de las sesiones del open space tuvo lugar durante los días 2 y 3 a la par de las sesiones predefinidas del programa.

Si bien algunas de estas actividades puede que ya no sean factibles para la edición de Agiles este año, hay otras que me parece que perfectamente podrían realizarse.

xp_party

XPConf 2016: Day 3 summary

The day started with a keynote by Professor Lionel Briand who talked about «Documented requirements are not useless after all». He presented really interesting stuff based on concrete study cases. I liked it.

After the keynote I joined the session «Working effectively with legacy Test» by Nat Pryce and Duncan McGregor. The session started with a short introduction by Nat and then we started reviewing test code shared by the participants. While sharing the code we analysed and proposed different possible refactors. I like the dynamics of the session.

Next I jumped to the session «Bourne Again, Bootstrap a testing framework in BASH» where Rob Westgeest coded a «xunit-like» tool in BASH to test BASH scripts. It was simple great! I loved the session and it gave me lot of ideas.

In the afternoon I followed Woody Zuill to his session «No Estimates», I was already familiar with the topic but I wanted to see how Woody presented it. I really liked his approach and I enjoyed the session.

The last session of the day (and the conference) was a Keynote by Steve Freeman and Nat Pryce.

The closing of the conference was in charge of Seb Rose who was the host of the conference.

In the next post I will share some highlights of the conference beyond the «formal stuff».

XPConf 2016: Day 2, our workshop

We were a bit worried because we didn’t know how many people would attend our workshop. The conference agenda for that day was full of interesting sessions and attending to our full-day workshop would imply missing all those sessions.

To our surprise we started the session with ~15 participants! After the ice-breaker activity we shared the full set of activities we had plan for the session and asked the participants to vote them, so we can concentrate in those more interesting for the audience. After voting, the final plan was not very different to what had prepared.

During the morning we presented our vision of XP «new practices» and drilled into one of them: Infrastructure as Code. These two topics generated some interesting discussion.

Before taking a break we checked with the audience how to continue. At that point some people left the session, but about the half decided to complete the workshop. So after a 30 minutes break we we jumped into Continuous Delivery, we reviewed the main concepts and we did a demo.

The next topic was User Story Mapping which only one of the participants knew about. We presented the technique and then we put it in practice.

The latest topic was Specification by Example, we explained the technique and put it in practice using Cucumber-JVM and working a «enterprise-like» application we built for the occasion. We work on a set of stories identified in the Story Mapping. For each of them we provided a ser of rules and asked the participants to work in pairs to write examples, validate them with US and them implement them.

As usual, at the end we asked for participant to rank the workshop and we get 4.3 out of 5 which for us was great! Here are some quotes form participants:

I really appreciated seeing Story Mapping and BDD in action –  especially the continuity between the two because they used the same example project.

 

Certainly a lot of valuable things covered and I learned a lot.

 

Definitely worth attending!

Here are some pictures and here is the slide deck we used (it does not have much information and because of that we are writing an booklet some participants can drill down in the different topics)

DSC05746

DSC05747

DSC05748

 

 

XPConf 2016: Day 1 summary

The journey started with a very interesting keynote by Elizabeth Hendrickson who shared how they at doing XP at scale in Pivotal Labs.

After that I went to the session Symbiotic Design Practices by Michael Feathers.

In the afternoon I attended the session Example Mapping by the Cucumber guys. The session was very interactive and I really liked the approach proposed by Matt and Steve (the guys in charge of the session). I will share my info about this session in a future post.

My next session was a Panel where some «agile rock starts» discussed about the Agile Hype. The session was fine but at a certain point I felt it was not adding value to me, so I left the room and went into the hall to do some networking.

At 6 PM I joined the Open Space Marketplace where I proposed a Smalltalk Introductory session for that same day.

At the 7 PM there was a nice Whisky Tasting activity and right after that I went back to the open space to join a session about Mutation testing. Next to it, was my Smalltalk session. Seven guys joined the session and we did a walkthrough over Pharo Smalltalk that took about one hour. By the end of the session it was almost 10 and I went to my room to review some stuff for the workshop I had to run the next day.

DSC05744
Elisabeth Hendrickson’s Keynote
DSC05745
Example Mapping Session

About our Modern XP tutorial @ XPConf 2016

Today we (@dfontde and me) will held this workshop that is focused on a set of practices we consider have take the main stage in software development over the last couple of years.

During morning we will review the foundations of XP and we will share a backlog creation technique called User Story Mapping.

In the afternoon we will continue with Infrastructure as Code, BDD, DevOps and Continuous Delivery. For this second part we will work with Java, Cucumber, Jenkins and Ansible.

Even when the workshop is full-day we invite xpconf participant to join either in the morning or in the afternoon. We think the workshop is great resource for those just starting with agile and also for those that are already practicing it but that would like to get familiar with the mentioned practices.

The workshop is based on our Software Engineer course at UNTreF University and we have already run it a couple of times with very good results.