Mes: abril 2018

De visita por España y Portugal

Del 21 al 25 de Mayo voy a estar participando de la conferencia XP 2018 que tendrá lugar en Porto, Portugal. En ese contexto, el lunes 21 por la mañana voy a estar dando mi Taller sobre Prácticas DevOps. Por otro lado, el martes 22 por la tarde voy a estar presentando junto a Diego Fontdevila el resultado de nuestro trabajo de investigación Technical and Organizational Agile Practices: A Latin American Survey.

Pero antes de todo esto, pasaré un par de días en Madrid y aprovecharé para participar de un Meetup de la comunidad Madriagil.  Estaré presentando una versión actualizada de la charla Patrones de Infraestructura para Continuous Delivery que presenté en año pasado en Agile 2017. Agradezco a Israel Alcázar por la organización del Meetup.

Más allá de estas actividades, si algún informático tiene ganas compartir unos tragos en algún punto de mi travesía, me escribe y coordinamos.

Un tercio de cuatrimestre en MeMo2@Fiuba

Hemos completado la sexta semana de clase y estoy conforme con como viene saliendo la materia. Tenemos 18 alumnos firmes, uno en la cuerda floja y uno que abandonó en la segunda semana.

La semana pasada hicimos una retrospectiva y las conclusiones fueron muy buenas a mi juicio. Entre los puntos positivos mencionados por los alumnos estuvieron los videos, la actividad de programación en clase, el material de lectura y el feedback dado en las correcciones de las tareas. Entre los action ítems resultantes acordamos trabajar en los siguientes 3:

  • Habilitar un espacio en el campus para debatir las preguntas de los cuestionarios
  • Seguir agregando más videos al material de estudio de forma de poder utilizar más tiempo de clase para actividades interactivas
  • Procurar que las preguntas de los cuestionarios que sean de tipo verdadero/falso tengan un campo de justificación

Self-Service Infrastructure Session accepted @ Agile2018

My session «Principles of Self-Service Infrastructure» was accepted at Agile 2018 ;-).

Here is the abstract of the session:

The management of development and test environments is a major concern when trying to optimize the value stream of any software development project. In this context, implementing Self-Service Infrastructure may help your organization to simplify the management of these environments. In this session we will review the foundations and benefits of Self- Service Infrastructure. We will also review the most common challenges and how to overcome them using some patterns. Finally we will see a set of tools to implement this practice and a couple of demos that will provide a better understanding of principles behind the tools.

Given that this is a brand new session I am planning to deliver it in a local meetup before Agile2018, so I can get some feedback.

 

Herramientas para gestión de backlog

Ayer recibí esta consulta de un colega:

«[…] te consulto porque estoy buscando para el banco una herramienta para Agile y seguimiento. ¿Tenes alguna recomendación al respecto?»

Esta es una consulta que he recibido varias veces y en primer lugar me veo obligado a decir que «la gestión ágil» no requiere de herramientas particulares y al mismo tiempo las herramientas toman un plano muy secundario. Ya lo dice el manifiesto «Individuos e interacciones por encima de  procesos y herramientas«.

Hecha esta aclaración mi respuesta a esta consulta suele tener dos partes.

En primer lugar suelo recomendar comenzar trabajar con un tablero físico y post-its. Hacer un par de iteraciones, refinar el workflow de estado de los ítems e identificar las necesidades reales en términos de gestión y seguimiento. Si el equipo no está distribuido o simplemente el tablero físico no es una opción, entonces comenzar utilizando una simple hoja de cálculo. Suelo recomendar esto porque en general que visto mucha gente comprando y/o adaptando herramientas a partir de elucubraciones teóricas, las cuales en muchos casos terminan plasmando en una herramienta un proceso «inventado de la nada» que poco tiene que ver con las necesidades de los proyectos.

Por otro lado, si quien me consulta alguien ya tiene en claro el workflow de estados y las necesidades reales (respaldadas por evidencia), entonces cuento mi experiencia:

  • Me gusta Jira, me parece una herramienta simple y muy flexible. Es paga y aunque no es muy cara, puede resultar inconveniente pagar por una herramienta sin tener en claro el proceso.
  • De las herramientas gratuitas me gustan Redmine y Trac, porque además de las funcionalidades de gestión de proyecto, ofrecen otra serie de cuestiones como Wiki e integración con herramientas de SCM. (los creadores de Jira también ofrecen herramientas adicionales como Confluence, que se integran con Jira y cubren funcionalidades adicionales).

 

Herramientas varias para Docker

Quiero compartir algunas herramientas que me han resultado muy útiles al trabajar con Docker/Kubernetes.

En https://access.redhat.com/containers/ se puede encontrar una interesante cantidad de imágenes Docker curadas por Red Hat.

El Red Hat Container Development Kit, es un conjunto de herramientas para facilitar el desarrollo de contenedores. Entre estas herramientas se encuentra una variante de Minishift.

Minishift una herramienta que permite correr un cluster de OpenShift de forma local en cualquier notebook.

Source to Image es una herramienta que permite crear imágenes de una forma repetible trabajando a un cierto nivel de abstracción sin necesidad de escribir Dockerfiles.

 

Tareas de un DevOp Engineer

Hoy un colega me consultó si tenía alguna descripción de las tareas que debería hacer un DevOp Engineer y eso motivo a escribir este artículo.

Debo empezar diciendo que no estoy muy convencido de que exista la profesión  DevOp Engineer, o sea: me consta que existe pero dudo que sea conceptualmente correcta su existencia. Al margen de esto: actualmente estoy trabajando como DevOps Engineer en un proyecto, ¡ja!.

Vamos por partes: la idea de DevOps es derribar los silos organizacionales para optimizar el flujo de entrega de valor. Si tenemos un área de operaciones y un área de desarrollo, deberíamos apuntar a que comiencen a trabajar de forma más integrada. En principio no creo que eso requiera de la aparición de un nuevo rol porque en principio no hay una nueva tarea. Alguien podría pensar que sí hay una nueva tarea dentro del grupo de operaciones (o del de desarrollo) y que esa tarea es encargarse de la interacción con el otro grupo. Esto podría tener sentido (de hecho es una de las tareas que estoy haciendo en mi proyecto actual) pero no estoy convencido porque se corre el riesgo de seguir operando como silos.

Por otro lado, dependiendo del estado en que nos encontremos, puede que como parte de la iniciativa DevOps decidamos empezar a utilizar nuevas herramientas (por ejemplo para automatizar tareas). Entonces podría tener sentido incorporar un nuevo rol con conocimiento de  dichas herramientas y de los conceptos que las mismas implementan. Este es justamente mi caso: la organización a la que pertenece el proyecto en el que estoy trabajando ha decido dockerizar su infraestructura y justamente esa la razón de mi involucramiento en el proyecto.

Dicho todo esto, podríamos decir que las tareas de un DevOp Engineer incluirían principalmente:

  • Facilitar el trabajo conjunto de las área de Desarrollo y Operaciones
  • Asistir a los equipos de Operaciones y Desarrollo en las tareas de definición e implementación de arquitectura (lógica y física) de aplicaciones
  • Asistir a los equipos de Operaciones y Desarrollo en la definición e implementación de la infraestructura de CI/CD
  • Asistir a los equipos de Operaciones y Desarrollo en la definición de procesos de monitoreo.

De estas tareas se desprenden una serie de habilidades/conocimientos de distinta índole: «soft-skills», configuration management, scripting/programación, operación, etc. A mi me suena que una persona aspirante a un puesto así debería tener bastante experiencia en la profesión.

Para cerrar: lo importante es que desarrollo, operaciones y el negocio trabajen en forma conjunta, coordinada e integrada para optimizar el flujo de entrega de valor, la incorporación de un nuevo rol para lograr esto es un detalle de implementación.

 

FLISoL 2018 en UNTreF

El próximo 28 de Abril se realizará el Festival Latinoamericano de Instalación de Software Libre_ FLISoL.

Este evento de alcance continental está destinado a la difusión del Software Libre, es completamente gratuito y está dirigido a todo público. Durante el evento se realizan instalaciones de software libre, se ofrecen charlas y talleres sobre diversas temáticas relacionadas al software libre. Todo esto en forma totalmente gratuita.

El evento se realiza simultáneamente el diversas sedes y este año por segunda vez, la Universidad Nacional de Tres de Febrero será una de sus sedes. Es en esa sede precisamente donde yo estaré participando.

Fixing the Ubuntu Xenial Vagrant Box

The official vagrant box of Ubuntu Xenial 64 was initially with a issue: it didn’t have a vagrant user (according to Vagrant recommendations all boxes should have a user with name vagrant and password vagrant).

A recent release fixed the problem in a partial way: the user vagrant was added, but it is not possible to use it with password authentication (a feature that I usually need in my workshops).

So to fix this issue I created a new vagrant box based on the official Xenial box. I added the following lines in the shell provisioner:

echo "vagrant:vagrant" | sudo chpasswd
sed -i -e 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config

The first line set the password vagrant for the user vagrant. The second line enables PasswordAuthentication.