En las últimas 2 semanas me encontré explicando la técnica de despliegue Blue/Green más de 5 veces. Cuando tomé conciencia de ello decidí hacer un video explicativo de modo de poder utilizarlo también en mis clases. Espero resulte de utilidad.
Autor: NicoPaez
Ansible vs Puppet: mi opinión
Hace unos días escribí sobre el camino que recorrí con las herramientas de automatización de infraestructura y mencioné que luego de haber usado Puppet y Ansible, he decidido quedarme con este último. Esta decisión se debe principalmente a las cuestiones:
- El DSL de Ansible me resultó mucho más amistoso que el de Puppet
- Para trabajar en modo «standalone» Ansible incluye en su core un conjunto de utilidades/tareas que a mi me resultan muy útiles y que no están en el core de Puppet (a menos que uno instale módulos adicionales).
- El modo de funcionamiento «push» de Ansible me gusta más que el modo pull de Puppet.
Resalté algunas partes de la frases anteriores para dejar bien en claro el nivel de subjetividad de las mismas.
Mi propuesta para el AOC 2016
Según el procedimiento de inscripción, tengo que responder 3 preguntas, asi que aquí voy.
¿Qué puedo aportar yo al evento?
Quiero aportar un entregable, algo concreto que trascienda los 3 días de conferencia y a los participantes de la misma. En concreto quisiera generar otro libro repitiendo y reutilizando la experiencia del libro Experiencias Ágiles que escribimos en el AOC anterior. No tengo del todo claro cuál sería el contenido de este libro, de mínima podría ser un conjunto de experiencias igual que el libro anterior, pero creo que tal vez podríamos generar algo un poco más rico como por ejemplo un catálogo de técnicas. Independientemente del tema, me gustaría llegar al evento con el contenido bastante avanzado para asi intentar cerrarlo durante el evento y evitar así una carga de trabajo post-evento. Si mi postulación es seleccionada imagino empezar a trabajar en enero. Creo que en primer lugar haría una convocatoria de autores y luego en conjunto con los que decidan participar deberíamos definir la cuestión del contenido.
¿Qué espero recibir del evento?
Espero encontrarme con otros practicantes para compartir experiencias en el desarrollo de software y también momentos de esparcimiento.
¿Quien soy?
Soy NicoPaez, un Ingeniero de Software formado en la Universidad de Buenos Aires. Practico basquet, me gusta escribir y jugar al TEG. Soy docente universitario y trabajo en la industria del software formalmente desde hace unos 15 años.
Agile Open Camp 2016: abierta la inscripción
La semana pasada se anunció la apertura de las inscripciones para el AOC 2016. Resulta que este año el procedimiento de inscripción tiene algunas particularidades.
A diferencia de otros eventos el AOC tiene un límite «duro» de asistentes pues es un evento 3 x 24, o sea son 3 días completos donde todos los participantes se alojan en un mismo lugar y comparten espacios las 24 horas. En la primera edición hubo mucha gente que quedó fuera por falta de vacantes. Si bien para esta segunda edición se contará con una mayor cantidad de vacantes también se espera una mayor cantidad de interesados en participar debido a gran repercusión que tuvo la primera edición. Es por esto que el grupo organizador ha decido experimentar con un sistema de inscripción alternativo al simple «orden de llegada» utilizado en la primera edición. El mecanismo a utilizar está explicado en este breve video de Tommy, unos de los miembros fundadores del evento.
En forma resumida la idea es: cada interesado en participar debe postularse indicando porque le interesa participar y que tiene para aportar. Luego cada uno de los 3 fundadores del evento revisa las postulaciones y selecciona 2. Los seleccionados se inscriben en el evento comprando su entrada y tienen derecho a elegir otros dos postulantes cada uno. El proceso se repite hasta completar la cantidad de vacantes disponibles.
Personalmente me gusta la idea de que las entradas se repartan en base a cierto criterio de «aporte de valor» en lugar de el simple orden de llegada. Veremos que tal sale, por mi parte ya me voy poniendo a escribir mi postulación.
Reflexiones sobre la automatización de pruebas
La semana pasada dicté junto a @dfontde un taller de automatización de pruebas. Entre la audiencia tuvimos principalmente desarrolladores.
Obviamente uno de los temas que tratamos fue la automatización de pruebas a nivel de Interface Gráfica de Usuario (GUI). De hecho cada vez que dicto este taller la gente suele venir con la expectativa de encontrar la bala de plata para poder automatizar pruebas exclusivamente a nivel GUI. Mi posición al respecto es siempre la misma: ¿en verdad que quieres automatizar pruebas a ese nivel?. A lo largo del taller trabajamos fuertemente sobre la cuestión de a qué nivel automatizar las pruebas y muchos suelen convencerse que puede resultarles más conveniente trabajar la automatización a nivel del API/Servicios.
Las pruebas a nivel GUI suelen ser frágiles (cambios mínimos en la GUI pueden romper las pruebas) y costosas de ejecutar (ya que requieren instanciar la aplicación completa). Pero al mismo tiempo pueden ser la única opción de automatización, ya que prueban la aplicación en modo caja negra, no importa como esté construida la aplicación pues simplemente se interactúa con ella desde afuera. Este es un punto muy relevante para el caso de aplicaciones legacy, que muchas veces han sido construidas sin características de testeabilidad. Más allá de estos argumentos que son clásicos y pueden encontrarse en la bibliografía hay algunas cuestiones adicionales que se han puesto de manifiesto en los últimos años.
- Por un lado cada vez son más comunes las famosas SPAs (Single Page Application), muchas veces basadas en frameworks «client-side»como AngularJS. Esto implica una creciente cantidad de código JavaScript. Este tipo de aplicaciones no suele ser tan simple de automatizar a nivel GUI pues no todas las herramientas no se lo bancan bien. Pero al mismo tiempo aparece un nuevo nivel de automatización posible: pruebas unitarias de los componentes JavaScript.
- Por otro lado, los frameworks de desarrollo / generadores de código «server-side» como Spring-Boot ya incluyen como parte de sus funcionalidades una propuesta para la codificación de pruebas automatizadas a nivel de API e incluso en algunos casos se encargan de generar el código de algunas de estas pruebas.
En mi opinión estas dos cuestiones refuerzan necesidad de repensar cualquier intento de automatización de pruebas a nivel GUI. Y quiero ser muy claro en cuanto a esto: no estoy diciendo que no se automaticen pruebas a nivel GUI, sino simplemente que no me parece una buena estrategia que el grueso de las pruebas automatizadas sea a nivel GUI. Creo que hay que pensar en una estrategia de automatización más integral que incluya pruebas a distintos niveles. Esto nos permitirá tener una mejor cobertura con un esfuerzo mucho menor y repartido entre los distintos perfiles del equipo (tengamos presente que el testing no es sólo responsabilidad de los testers).
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.
Se viene Agiles Argentina 2015
Este año la conferencia argentina de Agilidad se llevará a cabo en la ciudad de Rosario, en las instalaciones de la Universidad Tecnológica Nacional. Como de costumbre la entrada es libre y gratuita (pero con registración) y al igual que el año pasado el catering es auto-organizado. La agenda es 100% Open Space pero con un marketplace online disponible en http://aa2015.sesiones.agiles.org.
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:
- Hacer el desarrollo usando TDD
- Hacer integración commiteando al repositorio central (en el mainline) luego de cada nuevo test verde.
- Si el build se rompe, se para la línea hasta que sea arreglado
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?
Blog de NicoPaez 