El curioso incidente del Scrum Master y el merge a master

El curioso incidente del Scrum Master y el merge a master

Estábamos arrancando con el setup del proyecto y nos enteramos que el área arquitectura definió que el único que puede aprobar los merge-requests a master es el Maintainer. Curiosamente arquitectura asignó el rol de Maintainer en nuestro proyecto al Scrum Master, el único miembro del equipo (junto con el PO) que no codea, ¡ooops!

Ayer comenté esto en twitter y generó varias reacciones.

Lo que me incomoda de esta situación no es el hecho de quién puede aprobar los merge-request sino el hecho de que alguien externo al equipo defina cómo debe trabajar el equipo. Entiendo que haya ciertos lineamientos generales en cuestiones que puedan tener impacto fuera del equipo, pero cuestiones como el esquema de branching creo que no es una de esas cuestiones.

Al mismo tiempo quiero destacar que si bien recién estamos comenzando con el proyecto, la persona en el rol de Scrum Master me cae muy bien, creo que está haciendo un buen trabajo y si bien actualmente no codea lo hizo en el pasado.

Otra curiosidad es que en los lineamientos de arquitectura se asume en cierto modo que el equipo utilizará branches y merge-request, cuando en realidad la intención de nuestro equipo es hacer trunk-based development trabajando de pares para todo código productivo.

En fin, como conozco a uno de los referentes de arquitectura y me parece una persona bastante criteriosa y accesible lo llamé por teléfono para comentarle esta situación. Me explicó algo razonable: solo una persona por equipo tiene el permiso Maintainer y cuando se creo el proyecto el único miembro del equipo de desarrollo que estaba confirmado era el Scrum Master. Adicionalmente me explicó que lo que hizo arquitectura no fue establecer “reglas de piedra” sino lineamientos generales que surgieron del diálogo con diversos referentes de la organización y que pueden revisarse en cada caso particular. Esto también me resultó muy razonable. Más aún me parece muy sano cuando uno comienza un proyecto no se encuentre con la nada misma, está bueno tener algunos lineamientos que luego uno pueda debatir y eventualmente ajustar.

Cerrando la historia pinta que el equipo trabajará sobre un branch develop y luego en la salida a producción haremos el trámite de merge-master.

Preparación para el taller exploratorio de tcr

Preparación para el taller exploratorio de tcr

El jueves próximo en el contexto de la semana de la agilidad voy a estar haciendo un taller exploratorio de la dinámica tcr (test && commit || revert). Para ejercitar esta dinámica resulta muy conveniente tener algún mecanismo de file watching que (cada vez que modificamos un archivo) se encargue de correr los test y hacer commit o revert dependiendo del resultado.

Durante el taller yo voy a trabajar con Ruby pero el taller se puede seguir perfectamente con cualquier lenguaje, solo es necesario tener Git y un algún framework de automatización de tests (algo de la familia xUnit es suficiente).

Para quienes quieran trabajar con Ruby, armé un setup con una configuración Guard para correr el flujo trc. Está disponible GitHub.

Spring Config: a key tool for DevOps & Continuous Delivery

Spring Cloud Config (scc) is a tool that provides support to externalize application configuration in a REST Service. The big picture is:

  • Add a SCC client your application so when your application starts, it can fetch its configuration from SCC server.
  • Setup a SCC server, which is a Java REST Service (more specifically is a Spring-Boot application).

The following image offers a overview of how Spring Cloud Config fits in you application architecture.

Some benefits of this strategy are:

  • You decouple the evolution of your application from the evolution of the configuration, that is: you application will be the same in every environment while the configuration will be different in each environment. At the same time the change rate of your application is different from the change rate of the configuration.
  • Your application forgets about where the configuration it stored because it delegates that concern to SCC server.
  • SCC server supports several storage options: Git, File System, Vault, Database, ConfigMaps, etc. The default option is Git which is great because it “force” you to have your configuration versioned.
  • SCC provides several common features related to configuration management like: check the current configuration values, configuration reloading, encryption of secrets and support for different configuration formats among other things.

While working with SCC I faced some issues regarding how to specify its configuration so I want to share some details here.

To make SCC Server read configuration from a remote Git repository:

spring.cloud.config.server.git.uri=https://.....

(this would work fine for public repositories, but if you need to use a private repository, which is a common case, you will need to specify some more parameters like strictHostKeyChecking and privateKey that are very well explained in the official documentation). When SCC server starts, it will clone the remote repository into a local directory whose location will be generated randomly at runtime (but it is also possible to specify the clone location).

To make it work with a local git repository (which contains a .git subdirectory), just use:

cloud.config.server.git.uri=file:///your/local/git/repo

To make ir work with a local “plain” directory we need to specify active profile as “native” which makes SCC server to read the config from a plain local directory (not a git directory)

spring.profiles.active=native
spring.cloud.config.server.native.searchLocations=file:/your/directory

It worth mentioning that even when Spring Cloud Config is built on Java, you can use any client technology to consume it because it exposes a REST API. The Spring team provides a Java client, but there are also clients for other technologies.

 

Talleres segundo semestre 2017: DevOps, Continuous Delivery y Git

Para esta segunda mitad del año tengo planificado dictar los siguientes talleres:

  • Taller de Git, el martes 29 de Agosto, de 14 a 18 hs. en SADIO.
  • Taller de Continuous Delivery y Prácticas DevOps,  es un taller de 8 horas que dictaré el 15 de Septiembre en Kleer@Montevideo y el 3 de Octubre en Kleer@Argentina. El siguiente video explica brevemente el contenido del taller.

 

Taller de Git online (experimento gratuito)

Desde hace ya un par de años vengo incursionando en la educación online pero siempre en calidad de estudiante. Si bien en las materias que dicto suelo hacer uso de varios recursos online, el dictado formal sigue siendo presencial. La idea de hacer algo online me viene picando desde hace tiempo y esta semana finalmente decidí hacer mi primer experimento.

La temática será Git, una herramienta con la que vengo trabajando desde 2009 y aunque inicialmente no me gustó, desde 2011 la adopté como mi controlador de versiones preferido. Desde ese momento he realizado diversas actividades de difusión: cursos, charlas, artículos, etc. Ahora ha llegado el momento de tomar todos los materiales generados en estos años para darle forma a un curso online.

La idea es generar un conjunto de videos cortos (de entre 5 y 10 minutos) y complementarlos con ejercicios y lecturas además de ofrecer algunas sesiones online para consultas(posiblemente via Hangout o Skype). Mi idea es que el curso pueda completarse en unos 10 días, con una carga de trabajo de 30 minutos diarios.

Mi intención es largar la primera corrida experimental el lunes 20 de Abril. Si estas interesado en participar te pido que completes este formulario para que podamos coordinar el horario de los sesiones de consulta. Este primer experimento será totalmente gratuito.

Elegir un sistema de control de versiones

En más de una ocasión he sido consultado por organizaciones sobre la elección de sistemas de control de versión. Actualmente estoy trabajando con una organización que usa CVS y que está evaluando distintas herramientas para reemplazarlo.

Si bien basta con googlear un poco para encontrar miles de post sobre las diferencias, beneficios y problemas de los distintos sistemas de control de versiones, cambiar el sistema de control de versiones implica varias cuestiones no triviales.

Desde mi perspectiva estamos hablando de una herramienta que nos ayudará a resolver ciertas cuestiones de trabajo colaborativo y recalco esto: nos ayudará, la herramienta por sí sola no resolverá nada. Más aún, una herramienta mal utilizada puede traer más problemas que soluciones. Para que la herramienta nos permita resolver algún problema, debemos establecer ciertas reglas/convenciones para su uso (y luego respetarlas).

Dicho esto, deberíamos comenzar por identificar el/los problemas a resolver y luego analizar cómo es que cada alternativa de herramienta nos permitiría resolver esas cuestiones.

Desde mi óptica, hay 3 dimensiones de considerar en la evaluación.

Sistema de control de versiones: Git, Subversion, CVS, Mercurial, Darcs, son algunos sistemas de control de versiones. Para elegir uno posiblemente debamos comenzar por preguntarnos si queremos un sistema distribuido o centralizado y con ese punto de partida podremos ir acotando nuestras opciones. No voy a profundizar sobre este punto pues considero que es el que más desarrollado está y basta googlear un poco para encontrar pros y contras de cada uno.

Producto/Servicio: una vez elegido el sistema debemos elegir un producto o servicio que lo implemente. En este caso la discusión podría comenzar por: ¿queremos tener el sistema en nuestra infraestructura o preferimos contratarlo como servicio?. Una vez definido esto deberemos elegir un opción concreta. Ejemplo: supongamos que decidimos ir un sistema distribuido y concreto nos inclinamos por Git, entonces podríamos utilizar un servicio en la nube como el ofrecido por GitHub o Bitbucket o bien podríamos decidir adquirir un producto e instalarlo en nuestro entorno como podria ser GitLab o Stash.

Forma de uso: por más que hayamos elegido una producto/servicio concreto (supongamos GitLab), aún no basta para resolver nuestro problema, deberíamos definir ciertas cuestiones respecto de cómo usarlo. Esto implica responder preguntas tales como: ¿Cuál es el criterio para la creación de repositorios: creamos un único repo por equipo o creamos un repo por componente de nuestra solución? ¿usamos branches o forks? ¿cómo debería ser la estructura de cada repositorio?¿trabajamos todos sobre master o usamos feature branches?. Sin duda varias de estas cuestiones estarán influenciadas por la herramienta elegida pero más allá de eso, hay otra cuestiones que dependerán de problemática concreta de cada organización/proyecto.

En los últimos 2 años, he trabajado con al menos 5 organizaciones y en todos los casos la herramienta elegida ha sido Git. Si bien no siempre participé directamente en la elección de la herramienta, en varios casos estuve fuertemente involucrado en la definición de la forma de uso y la capacitación de los equipos.