Mes: octubre 2013

Taller de Integración Continua

La integración continua es una de las prácticas de ingeniería que más rápidamente permite comenzar a ver sus beneficios. A pesar de esto hay muchos equipos que no la utilizan, en parte porque sus miembros la desconocen. Al mismo tiempo, dar los primeros pasos con esta práctica requiere de un poco de experimentación de cara tomar algunas decisiones como: qué pasos i

ncluir en el proceso de integración qué herramientas utilizar, cómo configurarlas, etc.

Reiteradas consultas sobre estos temas nos llevaron a organizar este taller de integración continua. El mismo tendrá lugar los primeros días de diciembre en la oficinas de Kleer.

Les comparto el temario tentativo:

  • Fundamentos de la integración continua
  • Automatización del proceso de build
  • El rol de servidor de integración
  • Cómo elegir un servidor de integración
  • Instalación & Configuración básica del servidor de integración
  • Servicios de integración en la nube
  • Métricas y notificaciones

En los próximos días estaré compartiendo más detalles.

taller_ci

Definición de hecho y entrega limpia

En el contexto de los métodos ágiles suele hacerse mucho énfasis en la definición de hecho (definition of done). Esta definición puede variar dependiendo del contexto.

Personalmente desde que «vi la luz», mi definición de hecho consistió en:

  • El cumplimientos de condiciones de aceptación de la funcionalidad
  • El cumplimiento de las convenciones de codificación
  • El visto bueno por parte del Product Owner

Obviamente en cada nuevo proyecto procuro revalidar esta definición tanto con mi equipo como con el cliente.

Sin embargo, hace unos años empecé a ir por más. Ese «ir por más» tiene que ver con no sólo cumplir la definición de hecho, sino también  con lograr una entrega limpia. La idea es simple aunque puede no resultar fácil de explicar. Para intentar explicarlo voy a describir un contra ejemplo que me tocó vivir recientemente.

Resulta que un cliente necesitaba de una herramienta para resolver determinadas cuestiones de su deber cotidiano, pero debido a ciertas restricciones de agenda no podía involucrarse de lleno en el desarrollo de dicha herramienta. Como yo venía trabajando con él desde hacía un par de meses y conocía en profundidad la problemática a resolver, acordamos que yo ocuparía el rol de product owner. La herramienta fue construida en un par de semanas por un equipo de su organización cumpliendo con todos los «chiches»  (pruebas unitarias, de aceptación, integración continua, alta cobertura, etc, etc).
Luego de 2 semanas de finalizada la construcción de la aplicación, mi cliente se dispuso a ponerla en producción para empezar a utilizarla y entonces….¡chan! El procedimiento de instalación no estaba claro al igual que algunos requerimientos de runtime, lo cual llevó a varias horas de troubleshooting hasta que finalmente la aplicación quedó operativa. Esto es un ejemplo de entrega no-limpia.

Es muy posible que la situación pudiera haberse evitado si la aplicación se hubiera puesto en producción al final de la primera iteración, pero diversas cuestiones llevaron a que eso no fuera posible. Pero si miramos la situación a la luz de la filosofia de entrega limpia, esta entrega no fue limpia. Una entrega limpia habría incluido los pasos detallados para puesta en marcha de la aplicación  y no sólo eso, sino que dichos pasos habrían sido probados para asegurar que fuera correctos.

La entrega limpia tiene que ver con dar ese paso extra que finalmente termina haciendo la diferencia y deleitando al cliente.

NHibernate vs. Entity Framework: opiniones encontradas

En estos dias estoy arrancando un proyecto en .NET. Dado que estuve un poco alejado de este ecosistema por un tiempo, escribí un mail a un par de colegas de confianza consultándoles sobre cual de estos 2 ORMs utilizar.Las respuestas que recibí me hicieron reir bastante, cito textualmente:

«Nhibernate… EF es como los muñecos de una torta de casamiento, no se comen, son decorado.»

«Si la base es SQL server, andá por EF, no te compliques. Sino, anda por nhibernate pero con sharp-architecture.»

«NHibernate (EF sigue siendo una mentira)»

«ORM: Entity Framework, se que nhibernate ha mejorado mucho, pero EF con SQL anda muy bien.»

«ORM: EL DILEMA! Desde SW que no uso EF, y la verdad que me acostumbre a NHibernate, si te acordás de cuando lo usabamos en aquellas bellas épocas, es mejor aún. Con respectoa EF, esta última versión recién trae fluent mapping, no?»

También les consulté por inyectores de dependencias y las respuesta también fueron variadas, pero todas estuvieron de acuerdo en un punto: no a MEF.

Continuous Delivery en Agiles 2013

Durante la conferencia hubo varias sesiones sobre continuous delivery, una de ellas fue la mía. Dado que fue en el último turno del día intenté que fuera bastante movida, por eso arranqué con música y palmas, lo cual atrajo algunos curiosos que estaban en la cercanía de la sala.

Una vez terminó el ingreso del público hicimos tribus para así conocer el perfil de la audiencia. Resulto que había una audiencia dividida, la mitad no conocía continuous delivery y de los que sí conocían, sólo uno pocos tenían experiencia.

Yo personalmente quedé muy conforme con cómo salió la sesión y según el feedback que obtuve parece que los asistentes también se fueron conformes.

Durante la sesión conté con la colaboración de mi colega Luis Mulato.

Aquí están los slides que utilicé en la sesión y para quienes me preguntaron, el tema que sonó al comienzo de la sesión se llama Tapa de los sesos y es de Los Visitantes.

Algunas ideas para Agiles 2014

En el open space de Agiles 2013, Alan propuso hacer un Agiles 2014 radicalmente distinto. Entre las particularidades de la propuesta incluyó:

– Que la conferencia sea 100% Open Space
– Que no haya keynotes speakers
– Que haya un único nivel de sponsors

Personalmente me gusta esta propuesta y es en parte por ello que esto escribiendo este artículo.

El punto que más me gusta es el primero, pero el segundo me parece más importante.

Tradicionalmente desde la comunidad siempre hemos hecho un imporante esfuerzo en traer keynotes speakers extranjeros, llegando en un punto a menospreciar a los referentes locales. De hecho en las primeras conferencias no había keynotes speakers locales, lo cual puede en cierto modo justificarse por el hecho de que la comunidad estaba aún en formación. Personalmente creo que esa situación inicial ha cambiado mucho y creo que quedó en evidencia en Agiles 2013 donde el keynote speaker local (Gustavo Quiroz) fue incluso mejor que los keynotes speakers extranjeros.

No es que pretenda no tener keynotes speakers extranjeros, sino que me gustaría que en caso de tenerlos, los mismos sean de primer nivel. A mi entender los keynotes speakers que hemos tenido en los últimos años, aunque muy buenos, dudo mucho que puedan ser keynotes speakers de una conferencia mundial de Agile.

 

Agiles 2013, día 3

Al igual que el año pasado, el último día del evento fue en formato open space, pero comenzó comenzó con un keynote a cargo de Gustova Quiroz.

Luego del keynote, largamos con el open space. Al igual que viene ocurriendo últimamente, obviamos la parte de la votación y buscamos la forma de que todas las sesiones tuvieran su espacio. Curiosamente hubo una muy baja proporción de sesiones técnicas: alrededor de 5 sobre un total de más de 30.

De las sesiones que participé, me resultaron especialmente interesantes una propuesta por Janet Gregory en la hablamos sobre experiencias de automatización de pruebas y otra propuesta por JuanG en la que hablamos sobre las habilidades de los testers.

Gran parte de la tarde estuvo dedicada a sesiones relacionadas a cuestiones comunitarias como ser la selección del grupo de representantes/facilitadores, definición de la sede del año próximo, formato de la próxima conferencia, etc, etc.

En estas sesiones fue elegido un comité/grupo de facilitadores/representantes (llamenlo como gusten) conformado por 2 representantes de los equipos organizadores de las conferencias anteriores y 1 representante por cada pais de los presentes en la conferencia.
Luego un largo análisis y varias rondas de preguntas, el grupo de facilitadores eligió a Medellín (Colombia) como sede para la próxima conferencia. La otra ciudad candidata era Montevideo (Uruguay). La elección favoreció a Medellín por la mínima diferencia (1 voto).

Ya sobre las 6 de la tarde fue el cierre del evento, con facilitación de Alan y algunas palabras de los organizadores.
Aquí pueden ver un breve video de la dinámica de la máquina del sonido con la que cerramos el evento.

Luego del cierre, fue la retrospectiva del evento.

Ya por la noche fue el evento social el cual se llevó a cabo en «La peña del Carajo» y que entre pisco, cerveza, música criolla y cachengue, se estiro hasta horas de la madrugada.

Sobre la estructura de repositorio del código

Existen diversas posibilidades a la hora de armar la estructura de un repositorio de código. La elección de una u otra depende de diversos factores como ser: el tamaño del equipo, la forma de trabajo, la frecuencia de despliegue de la aplicación etc.

Quiero compartir dos estructuras posibles con las que he trabajado.

Estructura minimalista para Continuous Delivery

Contexto:

  • Tu aplicación es «standalone», en el sentido que tiene mínimas dependencias con aplicaciones externas
  • Tu equipo de desarrollo es chico (menos de 4 programadores)
  • Cuando debes agregar cambios/nuevas funcionalidades lo haces en pequeños incrementos
  • Cuentas con un alto porcentaje de cobertura
  • La regresión manual (en que caso que la necesites) te lleva menos de 30 minutos

Si se dan los puntos anteriores, entonces puedes ir fácilmente a un contexto de Continuous Delivery para lo cual recomiendo una estructura de repositorio basada en dos branches permanentes:

  • Develop: es el branch sobre el que se hace el desarrollo
  • Master: es el branch que contiene lo que se encuentra en producción

Cuando se está desarrollando una nueva funcionalidad, se va commiteando a develop. Cuando dicha funcionalidad está completa y ha sido vista por el responsable de producto en el ambiente de tests, entonces, dicha funcionalidad es mergeada en master y desplegada al ambiente productivo.

En caso de detectarse un error en producción, se crea un branch temporal (hot-fix) para desarrollar el fix que una vez completo es mergeado en master y develop.

Estoy asumiendo un ecosistema de trabajo que cuenta con un ambiente desarrollo (máquina del developer), una ambiente de tests (similar al de producción) y un ambiente de producción.

Estructura tradicional para desarrollo iterativo

Contexto:

  • Trabajas en un esquema iterativo con salidas a producción programadas en cada X días/semanas
  • Tu aplicación depende de otras aplicaciones/servicios externos
  • Tu equipo de desarrollo no es tan chico (más de 4 desarrolladores)
  • No tienes una buena cobertura, lo cual te lleva a ejecutar regresiones que llevan horas

En este caso también tendremos los 3 branches mencionados anteriormente (develop, master y hot-fixes temporales) pero adicionalmente tendremos otros branches:

  • Feature branch: cada funcionalidad es desarrollada en un branch aparte que luego es mergeado a develop
  • Release branch: es este branch se van a acumulando las funcionalidades listas para pasaje a producción. Puntualmente se hace un merge de develop a release branch

Este esquema es conocido como GitFlow y tiene cierta popularidad en el mundo Git, pero a pesar de ello es posible utilizarlo con otro controladores de versiones.

Agiles 2013, día #2

La jornada comenzó con el keynote de Janet Gregory quien habló sobre «el cambio». Me resultó bastante abstracto y algunos de los ejemplos que utilizó a mi entender no aplicaban a la realidad de latinoamérica.

A continuación asistí a la mejor sesión del día: Integrating Agile UX into your project. La misma estuvo a cargo de Rafael Petri y trató sobre diversas cuestiones de UX. Creo que me gustó tanto por tratarse de temas que siempre me han interesado pero en los que nunca he profundizado.

Luego seguí con la sesión Continuous Delivery with Mobile. En lo que hace específicamente a mobile la sesión aportó muy poco, pero me resultó muy interesante la forma en que fue explicado CD haciendo una analogía con la producción/consumo de café.

Ya el cierre de la mañana fue con la sesión de Mary Poppendieck, la cual estuvo dedicada al Lean Mindset. La sesión estuvo centrada en la presentación de casos e incluyó varias cuestiones del próximo libro de Mary.

Por la tarde, asistí a la sesión Current Testing Challenges de Janet Gregory, la cual me resultó muy interesante y me dejó varias cosas para pensar (próximamente post aparte sobre algunas cuestiones de testing que me surgieron de esta sesión).

La siguiente sesión fue la de Edson Chávez, un artesano de software que habló sobre su oficio. Si bien yo ya estaba familiarizado con el movimiento de software craftsmanship, la sesión me resultó muy entretenida por el estilo y los ejemplos utilizados por Edson.

Ya en el último tramo del día asistí a la sesión de Jorge Gamba sobre BDD. Estuvo bien, pero personalmente no me aportó nada nuevo.

La última sesión de mi día fue la de Angel Nuñez Salazar, quien habló sobre deuda técnica y presentó un modelo interesante para cuantificar su impacto económico. La sesión me gustó y me pareció muy innovadora pues nunca había visto nada de ese tipo.

El día terminó con una «sesión extraordinaria» en la que se debatieron temas de la comunidad, puntualmente se habló sobre el mecanismo de toma de decisiones de la comunidad, otro tema que también merece un post aparte.

Agiles 2013, día #1

El día comenzó con el keynote de Jurgen Appelo. Me gustó mucho, el mismo se tituló «Champs Frog». Podríamos decir que trató sobre un modelo para facilitar el cambio organizacional.

Luego asistí a una sesión titulada «Team of Leaders», la misma trató sobre liderazgo en equipos ágiles y básicamente fue un relato de la experiencia de los oradores. Estuvo bien, pero personalmente no me sumó nada nuevo.

La siguiente sesión que asistí fue de índole técnica y trató sobre testing de aplicaciones Andriod. Me resultó muy interesante y me llevé varias cuestiones para reveer. El orador fue bien claro y concreto.

Ya cerrando la mañana asistí a una sesión que prometía mucho «Diviértete en forma segura con Javascript», pero quedó sólo en la promesa, pues a las 10 minutos me retiré porque detecté que eran todos temas que ya conocía por demás.

Luego de compartir el almuerzo con Andy y Sole Pinter, asistí a la sesión de Jurgen Appelo, pero llegué bastante tarde ya que almuerzo se alargó más de lo debido, ¡ups!

La segunda sesión de la tarde fue de la JuanG que habló sobre planificación de la prueba. Como desde hace un tiempo, Juan no usó slides, sino un poster para facilitar la sesión, la estrategia presentada me resultó interesante.

Ya sobre las 5 de la tarde, estuve en la sesión de Gustavo Quiróz que presentó una técnica para retrospectivas enfocadas en propósitos. Estuvo bien.

Finalmente terminé el día con mi sesión sobre Continuous Delivery, pero eso será tema de otro post.

agiles_2013_dia_1

Resultado del Workshop de Git

Como había mencionado en un mail anterior, el martes pasado dicté un wokshop de Git en las instalaciones del MUG. Asistieron 16 participantes que era el máximo establecido.

Dado que Git es un herramienta muy potente y que hay un montón de temas relacionados al control de versiones, el workshop podría haber sido de 16 horas, pero lo habíamos planificado de 4, por ello al comenzar el workshop armé una lista de temas y le pedí a los asistentes que los priorizaran, de modo tal de poder regular el tiempo dedicado a cada uno de esos temas en concordancia con la priorización.

Más allá de algunos inconvenientes técnicos con la red, el workshop salió bien y los asistentes se manifestaron muy conformes.

Durante el workshop utilicé esta deck para explicar algunos conceptos y esta otra como cheatsheet.