Prácticas DevOps: unificación de ambientes

Una de las primeras recomendaciones que suelo hacer a quienes me contratan para ayudarlos con cuestiones de Continuous Delivery/Automazación de ambientes es la unificación/normalización de infraestructura. Lamentablemente suelo encontrarme con proyectos donde cada servidor/ambiente es una historia distinta: el servidor de producción corre una versión de sistema operativo distinta a la del servidor del producción, tomcat y apache instalados de distinta forma en distintas ubicaciones en cada uno de los ambientes. Situaciones de este tipo tienen dos problemas:

1. Existe cierto riesgo de que algo probado en testing luego no se comporte de la misma forma en producción debido a que los ambientes son distintos (y no me refiero a cuestiones de escala)

2. No es posible utilizar los mismo scripts de deployment/administración/monitoreo ya que muchas veces la ubicación de las aplicaciones/utilitarios es distinta en cada ambiente.

Ante situaciones así mi propuesta suele ser unificar ambientes/servidores siguiendo la heurística:

  1. Elegir un sistema operativo (y versión particular) en los posible que cuente con soporte de largo plazo. Ejemplo Ubuntu 14.04
  2. Automatizar el provisioning de base que tendran todos los servidores: configuración de usuarios, networking, etc. (es lo que seria automatización capa 1)
  3. Para cada componente (web server, base de datos, etc, etc) determinar la forma de instalarlo y generar los scripts correspondientes. (es lo que seria automatización capa 2)

De esta forma, cuando uno pretende avanzar sobre la automatización de despliegues, todo resulta mucho más simple ya que está claro el sistema operativo de base y la forma en que fue instalado cada componente. Al mismo tiempo, si todos los servers/ambientes se generan con los scripts de los pasos (2 y 3) entonces es muy factible poder reutilizar scripts de deploy entre distintos proyectos bajando de manera importante el esfuerzo de automatización.

Preparando Análisis y Diseño Orientado a Objetos en UNTreF

Por estos días me encuentro preparándome para dictar esta materia el primer cuatrimestre de este año. Si bien ya he dictado este materia en otras ocasiones esta vez tengo el desafío de dictarla solo, las veces anteriores la dicté en conjunto con @dfontde. En base al feedback obtenido de las dictadas anteriores y de algunas ideas que probando en otras materias, he decido hacer algunos ajustes a la dinámica de dictado de la materia.

El avance de internet, las redes sociales y la sobrecarga de información requieren que la dinámica de las materias se adapte, por ello más allá de la clase presencial semanal tendremos un modelo de aula extendida basado en un plataforma web. En base a esto se espera que los alumnos tengan una interacción constante con todo el grupo de estudio. Por cada hora de clase presencial se espera una dedicación de al menos una hora de trabajo fuera del aula. Dicho esto y pasando en limpio: los alumnos que cursen la materia deberán dedicar al menos 8 horas semanales todas las semanas. Dependiendo de cuanta maña pueda darse cada alumno, puede que la materia le insuma unas 6 horas semanales o puede que le insuma unas 10. El punto clave aquí es que a diferencia de otras materias no es posible llevar esta materia “haciendo la plancha” y estudiando a 30 horas seguidas los días previos a la evaluación. Se quiere una dedicación constante.

Respecto del mecanismo de evaluación no me gusta tomar examen escrito (aunque no lo descarto) y por ello estoy diseñando un mecanismo de evaluación basado en tareas semanales. La mayoría de estas tareas será de índole individual. Las tareas consistirán principalmente en lecturas con cuestionarios asociados y resolución de problemas de modelado y programación.

3 semanas de proyecto

El miércoles pasado se cumplieron 3 semanas/iteraciones desde que empecé a trabajar en mi proyecto actual. En estas semanas creo que hemos hecho algunos avances importantes respecto al producto y a la forma de trabajo:

  • Mejoramos “el teamwork”
    • ahora el equipo se sienta todo junto en la misma mesa
    • dimos un par de pasos para integrar a los miembros con asignación part-time (testing y UX)
    • creamos una lista de correo que tiene bastante vida y que nos permite estar más comunicados principalmente los días que hacemos homeworking
  • Respecto de los aspectos técnicos del proceso de desarrollo
    • tenemos 2 ambientes de testing: uno para tests automatizados y otro para tests manuales
    • agregamos tests automatizados
    • automatizamos el deployment a los distintos ambientes
    • empezamos a desplegar la aplicación en forma frecuente
    • ordenamos el versionado del producto agregando release notes y tags en los repositorios
  • Finalmente respecto del producto
    • hicimos un refactoring de arquitectura que gradualmente nos permite movernos de una arquitectura monolítica a una esquema de microservicios
    • como consecuencia del refactoring mejoró la estabilidad del producto

Personalmente estoy contento con como venimos avanzando y con los desafios que aún nos quedan por delante.

Continuará…

Consideraciones para habilitar el homeworking

El homeworking es una de las prácticas que a mi parecer está ganando gran popularidad en los ambientes informáticos. En particular en Buenos Aires existe hoy en día una gran demanda de profesionales informáticos y varias empresas “ofrecen como beneficio” la posibilidad de hacer homeworking 1 o 2 días por semana. Personalmente me gusta mucho el homeworking, yo soy bastante organizado y realmente logro ser muy productivo trabajando desde casa, sumado al hecho que me ahorro tiempo de viaje y caos de tránsito. Pero al mismo tiempo creo que es un cuestión que no debe tomase a la ligera.

Para empezar considero que el homeworking no es para todos. Ni para todos los proyectos, ni para todas las personas, ni para todas las organizaciones.

Hay proyectos en los que se requiere que la gente esté físicamente junta, tal vez no todo el tiempo, pero si en determinados momentos/temporadas (típicamente al comienzo del proyecto).

Al mismo tiempo, si una organización pretende habilitar el trabajo homeworking debe proveer cierta infraestructura para hacerlo posible, me refiero a cuestiones como algún sistema para conferencias online (skype, hangout, etc), acceso remoto a los servicios/servidores de la organización (ambiente de test, servidor de integración, sistema de tickets, etc, etc).

Finalmente respecto de las personas, es necesario saber organizarse y tener cierto nivel de autonomía en el trabajo. Este último punto no es trivial, pues la autonomía requiere ciertos conocimientos, tanto del contexto/organización como también de las tecnologías a utilizar.

Por otro lado hay un “anti-patrón” que he visto en varias ocasiones: tomar el homeworking como “obligación”: “yo los miércoles trabajo desde casa” cuando en realidad me parece que debería ser algo más del estilo “yo los miércoles intento trabajar desde casa, pero si el proyecto/contexto lo requiere vemos como manejarlo (obviamente procurando no perder el beneficio ;-) )“.

Chat no mata mail

En el último año he visto muchos equipo comenzar a utilizar herramientas de chat comunitario. Slack, Campfire, HipChat y Gitter son algunas con las que tuve la oportunidad de trabajar. Algunos equipos suelen utilizar este tipo de herramientas como medio de reemplazo del mail, integrando con las mismas todas la notificaciones y reemplazando así aquellas notificaciones que tradicionalmente se recibían por  mail.

Si bien me parece que estas herramientas pueden resultar útiles para determinadas situaciones creo que de ninguna manera reemplazan al mail. En mis proyecto me gusta siempre contar con lista de correo independientemente que se cuente o no con una herramienta de chat comunitario.

Personalmente me resulta mucho más cómodo el uso del mail para mantener discusiones asíncronas las cuales a mi parecer no resulta cómodo manejarlas vía chat. El chat me parece genial para mantener discusiones en vivo cuando uno requiere interacción inmediata pero no para estos casos de respuestas no urgentes y tardías. Al mismo tiempo tengo la sensación que entrar a un chat y ponerse a revisar mensaje viejos es extremadamente incómodo.

Voy a ejemplificar con algunos casos para los que considero que una lista de mail resulta mucho más apropiada que el chat.

  • Discusiones de refactoring: estoy codeando y veo a la pasada algo que no me cierra y que me parece merecería un refactor pero que no es trivial de realizar. Entonces planteo la discusión por mail pues no es algo urgente. De esa forma cada uno puede responderlo cuando lo considere apropiado y una vez lograda una decisión vemos de agendarlo para trabajar en una iteración futura (posiblemente con una charla presencial de por medio)
  • Diseño de producto: similar al caso anterior pero desde la perspetiva de producto, se me ocurre que se podría agregar/modificar una funcionalidad, entonces inicio una discusión por mail con el Product Owner y el equipo para ir hablando el tema antes de llegar a la próxima planning.
  • Intercambio de información con miembros externos al equipo: tengo que avisar a mi comunidad de usuarios que se realizará una tarea de mantenimiento de la aplicación, entonces mando un mail con este aviso y pongo en copia oculta la lista de correo del equipo desarrollo. De esta forma el equipo tiene presente la tarea de mantenimiento y está al tanto que los usuario ya fueron notificados.

En forma resumida mi opinión es: Chat no mata mail.

Más de 10 años de blogging

Ayer por casualidad caí en la cuenta de que hace 10 años que escribo este blog, aunque no siempre estuvo hosteado aquí. Actualmente este blog está hosteado en WordPress, pero antes de llegar aquí pasó por otras plataformas.

Mi primer blog lo empecé a escribir en 2006 con el fin de llevar una bitácora de mi trabajo en mi tesis de grado, por ello el blog estaba dedicado a cuestiones de Programación Orientada a Aspectos. Ese primer blog estaba hosteado en Blogger.

Un par de meses después, mientras trabajaba en Microsoft empecé a escribir un segundo blog en el cual escribía principalmente sobre cuestiones relacionadas a mi actividad profesional en Microsoft (la difusión de tecnología .Net) y de vez en cuando colaba alguna que otra entrada sobre cuestiones de agilidad.

En mi paso por Snoop y Southworks también escribí algunas entradas en sus respectivas plataformas de blogging.

Cuando finalmente me mudé a WordPress, traje conmigo las entradas de mis blogs anteriores.

A lo largo de estos 10 años también he ido alternando el idioma. En algún momento se me había dado por escribir en inglés, simplemente para practicar mi escritura en ese idioma. Luego, cuando empecé a dedicar la mayor parte de mi escritura a cuestiones de agilidad, me pareció importante escribir en castellano, pues en aquel momento escaseaba el contenido sobre agilidad en castellano. Actualmente escribo casi todo el tiempo en castellano y dejo el inglés para algunas situaciones muy particulares como cuando asisto a conferencias fuera de Latam.

A los largo de estos años la cantidad de visitantes del blog ha ido en aumento, pero sinceramente no es algo que me preocupe, pues en la mayoría de los casos escribo para mismo, ya sea a modo de recordatorio de como resolver un determinado tema o bien como bitácora de los proyectos en  los que voy participando.

Al día de hoy este blog cuenta con 763 artículos y en los últimos años he tenido un promedio de publicación de ~100 artículos/año, lo cual representa algo asi como un artículo cada 3,6 días. Nada mal, aunque a pesar de la práctica aún no estoy conforme con la calidad de mi escritura.

Este año tengo pensado volver a trabajar en un investigación, con lo cual sospecho que la la cantidad de entradas puede llegar a estar por encima del promedio.

 

Convocatoria de autores para el libro del AOC 2016

La semana pasada me informaron que mi postulación para el AOC había sido aceptada, con lo cual está confirmada mi participación en la conferencia.

La propuesta que envié como parte de mi postulación era para escribir un libro similar al del año pasado pero dando una vuelta de rosca sobre el contenido. El libro que escribimos (y publicamos) el año pasado era un compendio de experiencias.

Este año me gustaría que el libro sea un compendio de técnicas. Creo que existen en la actualidad diversas técnicas comúnmente utilizadas en el desarrollo de software que no están (hasta donde yo sé) formalmente documentadas en castellano. Me vienen a la mente técnicas como Impact Mapping y Mob-Programming. Al mismo tiempo creo que todo equipo luego de alcanzar cierto grado de “madurez” empieza a generar sus propias técnicas/prácticas/costumbres que bien pueden resultar de utilidad para la comunidad de practicantes. Me vienen a la mente el Delivery Map usábamos en Southworks y el ApplicationStatus que suelo utilizar en mis aplicaciones.

Por otro lado también quisiera hacer un cambio en la dinámica, me gustaría que este año lleguemos a la conferencia con todos los capítulos ya escritos, de manera que el tiempo dedicado en la conferencia sea para tareas de edición y revisión.

Con este artículo abro la convocatoria de autores para este segundo libro. Los interesados en sumarse a esta iniciativa por favor contactarse conmigo.