Caminando las herramientas de automatización de infraestructura

En mi opinión hay 3 herramientas que han picado en punta en esta temática: Chef, Puppet y Ansible. Hay algunas otras (como por ejemplo CFEngine) pero toda la gente y casos que conozco utilizan alguna de las 3 mencionadas. En mi caso cuando comencé a meterme en este campo di una primera mirada a Chef, tenía por aquella época un cliente a quien yo estaba ayudando con otras cuestiones y que usaba Chef para administrar su infraestructura. A partir de ello hice algunas pruebas con Chef, pero nunca lo use en un «proyecto real».

Poco tiempo después me salió un proyecto para automatizar todo el pipeline de deployment de un aplicación incluyendo el proceso de provisioning de ambientes. Las pruebas que había hecho con Chef no me habían convencido, asi que decidí probar con Puppet. Usé Puppet durante un buen tiempo en diversos proyectos hasta que este año trabajé en un proyecto con Ale Ferrari quien venía utilizando Ansible y en mi siguiente proyecto decidí probarlo.

Hoy en día mi elección es Ansible, pero las razones las compartiré en otro post.

El desafio del Open Space

He tenido la oportunidad de participar de más de 20 Open Spaces de Agile, en diversas ciudades de Argentina, Latinoamética y Europa. Y si bien Open Space se ha convertido en mi formato favorito de conferencia, he observado un patrón que creo que le juega en contra. En todos los Open Spaces que he participado, he la gran mayoría de las sesiones han carecido de preparación previa, incluso en aquellos casos donde existía la posibilidad de proponer sesiones en forma previa a la conferencia. Esta «improvisación» (falta de preparación) a la hora de proponer sesiones, termina en muchos casos generando sesiones desordenadas o de «baja calidad». Insisto en que no creo que esto sea una limitante del formato, sino una característica (negativa a mi parecer) de cómo la comunidad Agile utiliza este formato.

@acyment viene insistiendo desde hace un tiempo en que la conferencia Latinoamericana de Métodos Ágiles sea 100% Open Space. Personalmente apoyo esta idea pero considero necesario darle una vuelta de rosca a la cuestión para intentar asegurar sesiones «de calidad». Como mencioné hace un tiempo, creo que el punto de partida es hacer el marketplace en forma anticipada con alguna herramienta web. Eso debería permitir que la gente proponga sus sesiones y también que reciba feedback de las mismas. Al mismo tiempo permite tener una idea general de los temas y oradores de la conferencia, lo cual suele ser muy importante para gente sin experiencia en Open Spaces.

La semana próxima tendremos la conferencia Ágiles Argentina 2015 en formato 100% Open Space y ya está disponible la plataforma para proponer sesiones asi que ahí vamos, a experimentar.

 

Talleres de fin de año (2015)

Una vez alguien me dijo que una buena forma de aprender algo es intentar explicarlo y desde entonces me metí a la docencia. En los últimos dos años he participado en diversas iniciativas de DevOps y para terminar de afianzar lo aprendido he diseñado dos nuevos talleres, uno de prácticas DevOps y otro de desarrollo Java sin Fricción. Estos dos talleres los voy a estrenar en breve a la par de mis clásicos talleres de Git y automatización de pruebas. En resumen este es mi calendario de talleres de fin de año:

  • Taller de Integración Continua, 26 de noviembre, en SADIO (más info)
  • Taller de Automatización de pruebas, del 23 al 26 de noviembre en Grupo Esfera (más info)
  • Taller de Git, 4 de diciembre en el Polo Tecnológico de Rosario (más info)
  • Taller de Prácticas DevOps, 15 de diciembre en Kleer (más info)
  • Taller de desarrollo Java sin fricción, 16 de diciembre en Grupo Esfera (más info)
  • Taller de Git, 17 de diciembre en el MUG (más info)

Dudas o consultas no duden en escribirme.

Ejercicio: interpretación de métricas de test y cobertura

Amo las métricas, creo que es un efecto colateral de la búsqueda de la mejora continua. Para mejorar es necesario medir, pero con medir no basta, hay que saber qué medir y luego hay que interpretar lo medido para poder accionar al respecto.

Hoy quiero compartir un actividad que hicimos esta semana con mis alumnos de Ingeniería de software en UNTreF. La dinámica fue simple, dado un proyecto tomamos los gráficos de evolución de tests y cobertura generados por Jenkins y los analizamos para generar hipótesis a partir de ellos. Invito a los lectores a sumarse a este ejercicio, analicen los gráficos e intenten extraer información de ellos. Comparto un poco de contexto que les puede resultar útil para el análisis: el proyecto en cuestión es un modelo (o sea pura lógica, sin UI ni base de datos), los desarrolladores son alumnos universitarios que tenían que trabajar con 2 consignas:

  1. Hacer el desarrollo usando TDD
  2. Hacer integración commiteando al repositorio central (en el mainline) luego de cada nuevo test verde.
  3. Si el build se rompe, se para la línea hasta que sea arreglado

analisis_1

Aquí va mi análisis y con mis hipótesis/conclusiones (=>):

  • En el build #10 se agregaron 10 tests => no respetaron la consigna 2
  • Pero a pesar del agregado de tests la cobertura disminuyó => posiblemente por el agregado de código de dominio sin los correspondientes tests => violación de la consigna 1
  • En los siguientes builds (#11,#12 y #13) la cantidad de test aumenta de a uno y también se evidencia un aumento en la cobertura.
  • En los builds #14 y #15 se evidencian nuevamente saltos grandes en la cantidad de tests y de la mano de ello también un aumento de la cobertura.
  • Entre los builds #15 y #18 la cantidad de tests se mantiene constante y lo mismo ocurre con la cobertura => esto podría indicar pasos de refactoring.
  • En el build #19 disminuye la cantidad de tests y con ello la cobertura => esto podría deberse a un cambio en el código de dominio que no fue acompañado completamente por la correspondiente actualización de test.
  • Finalmente la cantidad de tests se mantiene constante en los últimos builds pero la cobertura disminuye => me hace pensar en agregado de código sin los correspondientes tests.

¿algo que agregar?

Convenciones de trabajo

Desde que trabajo en forma independiente suele ocurrirme que de tanto en tanto me toca trabajar con gente nueva. Obviamente no toda la gente trabaja de la misma forma ni con las mismas convenciones. Es por esto que hace un tiempo decidí tomar un enfoque bien explícito respecto a convenciones de trabajo de cara a evitar eventuales fricciones. Comparto aquí algunas de las convenciones de trabajo que suelo utilizar

Reunión acordada = reunión agendada

Muchas veces las reuniones se coordinan hablando, pero para que realmente ocurran en tiempo y forma encuentro la necesidad de agendarlas. Ya lo decía uno de mis primeros jefe «If you don’t schedule it, it won’t happen«. Es por esto que una vez acordada la hora y lugar de reunión suelo poner la reunión en mi agenda y enviar una invitación a todos los participantes. Adicionalmente, dependiendo del tipo de reunión suelo agregar en la cita el temario a tratar.

Hora de agenda  = hora de inicio

Los horarios muchas veces son un tema delicado. Personalmente cuando agendo una reunión a las 10.00 espero que la reunión comience a las 10.00, ello implica que todos los participantes esten presentes al menos 1 minuto antes en la sala de la reunión. Esto que a algunos nos parece trivial, no lo es para todo el mundo. Mucha gente parece entender que si la reunión está agenda a las 10:00, entonces esa es la hora en que se disponen a trasladarse hacia la reunión, lo cual ocasiona obviamente que la reunión arranque bastante más tarde. Algunos otros interpretan que las 10.00 es hora en que deben ingresar a la sala de reunión, lo cual hace que entre que saludan, se sientan, se acomodan, abren el cuaderno/notebook, tardan al menos 5 minutos más para poder comenzar con la reunión. Situaciones similares ocurren con la hora de finalización. Hay gente que llegada la hora de fin, sigue con la reunión como si nada. Personalmente lo que suelo hacer cuando está llegando el final de la reunión es intentar redondear y eventualmente consultar a los participantes si están de acuerdo con estirar la reunión algunos minutos más (siempre indicando cuantos minutos más) para poder cerrar la reunión ordenadamente.

Mail recibido, mail respondido

Cuando mando un mail de trabajo con consultas/validaciones, espero un respuesta en un plazo no mayor a 36 horas hábiles. Obviamente yo mismo suelo responder en ese plazo cuando soy quien recibe los mails. Incluso cuando la respuesta sea un simple «OK«, espero recibir un mail, pues de lo contrario queda la duda de si el destinatario leyó el mail, está de acuerdo y no respondió por no tener nada que agregar o si no respondió por haber recibido/leído el mail.

Notas de reunión

Luego de cada reunión donde se toman decisiones suelo mandar un mail compartiendo un resumen de lo hablado incluyendo los puntos destacados y si las acciones siguientes (si las hubiera). Del mismo modo espero que en caso de no poder asistir a una reunión sobre una cuestión en la que estoy involucrado, espero que alguien comparta las notas de los hablado.

 

Lamentablemente no siempre logro que todo el mundo adhiera a estas convenciones, pero cuando lo logro realmente me evito muchas fricciones.

Taller de Prácticas DevOps

Aquellos que siguen mi blog saben que desde hace ya hace ya un buen tiempo vengo trabajando fuertemente con prácticas DevOps. Además de aplicar estas prácticas en mis propios proyectos de desarrollo, también he estado involucrado en iniciativas de automatización en grandes empresas como OLX y Technisys. Todo esto me ha permitido acumular experiencia, conocer herramientas y probar distintas estrategias de implementación.

Con la excusa de bajar de tierra todo este conocimiento/experiencia y compartirlo, hace un tiempo comencé a preparar un curso. El título por el momento es «Taller de prácticas DevOps»,  pero más allá del título, la idea es conocer/repasar un conjunto de prácticas (y herramientas asociadas) que han cobrado popularidad en los últimos años y que tienen un impacto directo en el time-to-market y la capacidad de responder a cambios de negocio en forma rápida desde las área de sistemas. El programa preliminar del curso es:

  • El movimiento DevOps
  • Prácticas DevOps: automatización y versionado
  • Un vistazo a las herramientas infraestructura : Chef, Puppet y Ansible
  • Un vistazo a las herramientas virtualización: Vagrant y Docker
  • Casos de reales de implementación
  • Recomendaciones para dar los primeros pasos

La primer edición de este taller la dictaré en las oficinas de Kleer en Argentina el próximo 15 de diciembre. Más información aquí.