El impedimento de “ser especial”

Creo que la mejor forma de explicar mi punto es con un ejemplo concreto. La cuestión es más o menos así:

  1. Me contacta una persona de una organización para mejorar algún aspecto de su proceso de software delivery.
  2. Agendamos una charla.
  3. Hablamos un rato, primero escucho, pregunto algo y sigo escuchando.
  4. Luego le cuento a mi interlocutor algunas cuestiones de mi forma de trabajo.
  5. Preguntas, respuestas, escucho, pregunto, respondo y finalmente acordamos (a pedido mio) coordinar una reunión con la gente que está en “la trinchera”
  6. En esa reunión con “la gente de la trinchera” yo intento validar la situación problemática descripta inicialmente por quien me contactó. Para ello escucho y pregunto. A medida que voy confirmando la situación voy haciendo alguna pregunta/sugerencia del tipo “¿Y ante eso probaron XYZ?” siendo XYZ típicamente una práctica ampliamente difundida.
  7. Es en ese punto donde aparecen respuestas del tipo “XYZ no funciona aquí porque este es un contexto especial”

Ahí está, el primer impedimento para el cambio y la mejora. Gente que tiende a creer que es especial, que tiene problemas que nadie más tiene, que su problema es único y nadie más en el mundo lo tuvo.

Bueno amigos, tengo una noticia, no sois tan especiales

“Es que nadie tiene que lidiar con el incompetente de mi jefe” y tal vez sea cierto, pero seguramente hay gente que tuvo que lidiar con jefes mucho más incompetentes. Y lo superaron.

No pretendo herir los sentimiento de nadie, tal vez seas especial, pero eso no implica que tu problema no tenga solución o que tu situación no tenga chances de mejora o ninguna de las prácticas/técnicas ampliamente probadas no puedan intentarse en tu contexto.

Un patrón que encuentro en estos casos es que “la gente especial” muchas veces ni siquiera hace el intento. No se preocupan en estudiar seriamente el problema y sus posibles soluciones. Se quedan en “su caso especial”. Caso típico “este contexto es muy especial no podemos estimar” ¿y cuántos libros/artículos leyeron sobre estimación? ¿cuántas técnicas probaron? La respuesta suele que nunca leyeron nada, o que tal vez leyeron algo en una materia en la universidad pero ni siquiera recuerdan lo que fue.

No está mal pensar que somos especiales (pues tal vez lo seamos), pero por favor que eso no sea un excusa para evitar el esfuerzo de intentar mejorar.

Para cerrar les comparto un breve fragmento de la película Los Increibles: “Decir que todo el mundo es especial es otra forma de decir que nadie lo es” 🙂

(adelantar hasta 1:57)

De Gitlab a Azure Kubernetes Service

IMPORTANTE: escribo este post principalmente como una nota personal para futura referencia. El procedimiento que describo aquí es el que seguimos para hacer el setup de la infraestructura que utilizamos para el trabajo final de memo2@fiuba. En este contexto de cara a no tener dependencia fuerte con ningún proveedor hemos decidido armar nuestra infraestructura sin hacer uso de ninguna característica particular de las herramientas de ningún vendor. Es por eso que este procedimiento podría utilizarse con mínimos cambios para conectar con cualquier otro proveedor de Kubernetes y al mismo tiempo también podrían utilizarse con otra herramienta de CI/CD que no sea GitLab. En este caso estamos utilizando las suscripciones educativas tanto de Azure como de GitLab.

Creación de cluster

Al crear el cluster simplemente elegimos el tamaño de nodo, en nuestro caso B2S y especificamos 2 nodos. Adicionalmente debemos especificar un grupo para los recursos que se crearán como parte del cluster, en nuestro caso pusimos “memo2” y obviamente necesitamos un nombre para cluster, en nuestro caso “cluster-memo2-prod”. Finalmente desactivamos la funcionalidad de monitoreo porque está fuera del scope de nuestra suscripción. Esto representa un costo mensual aproximado de ~ us$ 73, lo cual está bien ya que la suscripción nos ofrece 100 dólares de crédito y nosotros solo necesitamos el cluster 1 mes.

Una vez creado el cluster, el siguiente paso es descargar la configuración de conexión para kubectl (el cliente kubernetes). Para esto es necesario en primera instancia utilizar el azure-cli. La opción obvia es instalar el azure-cli, pero también está la opción de usar un “cloud shell” de azure que nos abre un shell en la ventana del navegador y que tiene el azure-cli instalado. Una vez que tenemos el azure-cli a mano (ya sea instalado en nuestra máquina o usando el cloud shell) debemos ejecutar los siguientes dos comandos:

az account set --subscription <subscription id>
az aks get-credentials --resource-group <resource group> --name <cluster name>

El segundo comando “instala” la configuración para conectarnos al cluster, lo cual significa que tenemos un archivo en ~/.kube/config con todos los parametros de configuración de conexión. Ejecutando “kubectl version” deberíamos ver la versión de nuestro kubectl y la versión de kubernetes que corre el cluster.

Con esto ya estamos en condiciones de conectar nuestro GitLab con el cluster creado.

Conexión Gitlab > Kubernetes

El primer paso, es crear una cuenta de servicio para que gitlab se conecte al cluster. Esto lo hacemos con este manifiesto.

Una vez creada la cuenta de servicio necesitamos obtener su token para lo cual ejecutamos los siguientes comandos:

# primero creamos la cuenta de servicio
kubectl apply -f gitlab-service-account.yaml

# luego buscamos entre los secrets el correspondiente a la cuenta creada
kubectl get secrets

# finalmente hacemos un describe del secret para poder obtener su token
kubectl describe secret <nombre del secret>

Ya con todo esto podemos proceder la configuración del cluster en GitLab

En el formulario de configuración del cluster completamos los campos de la siguiente forma:

  • Kubernetes cluster name: el nombre con el cual queremos identificar el cluster, en mi caso “cluster-memo-prod”
  • Environment scope: el ambiente que este cluster representará, en mi caso será “prod”. Este ambiente luego será referenciado dentro del pipeline de CI/CD
  • API URL: la sacamos de la configuración de kubectl, es el campus server. Lo podemos obtener haciendo “cat ~/.kube/config | grep server
  • CA Certificate: también lo obtenemos de la configuración de kubectl haciendo “cat ~/.kube/config | grep certificate-authority-data“. Pero, adicionalmente hay que desencodearlo, entonces podemos poner el valor en una variable y ejecutar: “echo $CERT | base64 -d
  • Service token: aquí utilizamos el token de la cuenta de servicio que creamos previamente
  • RBAC-enabled cluster, GitLab-managed cluster, Namespace per environment: en el caso de MeMo2 no hacemos uso de ninguna de estas funcionalidades con los cual dejamos las 3 opciones como unchecked
  • Project namespace prefix (optional, unique): esto tampoco lo utilizamos con lo cual no dejamos en blanco

Algunas reflexiones a 20 años del manifiesto ágil

En estos días se están cumpliendo 20 años de la publicación del manifiesto ágil. Mucha agua ha corrido bajo el puente.

Agile se volvió mainstream (¿hacia ~2010?).

Alguna gente llegó, probó y se fue (¿los menos?).

Otra gente llegó, se enamoró y ahora abraza árboles (¿demasiados?).

Están también los fundamentalistas, que incorporaron Agile a su vida y evangelizan con Agile a todo el que se cruza (¿coaches?).

Están también los pragmáticos no fundamentalista que ven los métodos ágiles como una herramienta útil para ciertos contextos pero que no dudan en dejar Agile de lado si ven un enfoque que calza mejor para el contexto (¿yo?)

Obviamente también hay gente que aún no llegó (¿llegarán algún día?).

Como dirían algunos amigos, también están los “vende humo” (como en todo negocio ¿no?)

Siempre que hay una moda, están los contra, en este caso los “anti-agile” que, en gran medida debido a los abrazadores de árboles y a los vende humo, creen que Agile es puro cuento y militan en su contra.

Sin duda podríamos seguir enumerando posiciones respecto a Agile, pero creo que con esto basta para exponer la situación.

El término “agile” a mi entender ha perdido un poco de significado, ha sido utilizado para referirse a cosas muy distintas, basta ver algunas conversaciones de twitter para confirmarlo.

Uno lee el manifiesto y en los primero años de los 2000, hablar de Agile es prácticamente XP, equipos chicos, autogestionados, que construyen software con excelencia técnica, tal como sugiere el manifiesto. Hacía el 2010 la situación cambia y Scrum toma el lugar de mayor popularidad. Nos inundan los post-its. Empezamos a ver equipos agile que no construyen software con excelencia técnica (Flaccid Scrum). Tiempo después aparecen los enfoques de escalamiento y todo el “Agile Industrial Complex” y los equipos casi que dejan de ser autogestionados y cierta burocracia renace. Esto da origen a un movimiento “revolucionario” de vuelta a las raíces y los enfoques de Modern Agile y Heart of Agile empiezan a cobrar relevancia en contraposición a las propuestas de escalamiento como SAFe.

En fin, realmente hay discusiones y usos de Agile que son de lo más diverso. Pero hay un hecho innegable: agile ha tenido un importante impacto en IT tanto a nivel industrial como académico. Y a mi parece ese impacto ha sido muy positivo.

Justamente con motivo de estos 20 años de Agile, estas semanas se han organizado diversos eventos relacionados a Agile. En mi caso estaré participando este viernes 12 de febrero en un conversatorio con formato fishbowl sobre DevOps. Este evento es organizado por la gente de RunRoom. La participación es gratuita pero requiere registración aquí.

Cucumber modo dual

Cucumber es la “herramienta insignia” de BDD. Permite escribir ejemplos (pruebas) ejecutables utilizando Gherkin, una sintaxis amistosa para gente no técnica.

Una de las particularidades de Cucumber es que provee una muy buena experiencia para el desarrollador pues tiene la capacidad de instanciar dentro del mismo proceso la ejecución de la pruebas y la aplicación a probar incluso cuando la aplicación bajo prueba es una aplicación web[*]. Esto tiene algunas implicancias interesantes como ser:

  1. Las pruebas corren mucho más rápido (comparado a si corrieran pruebas y aplicación en procesos separados) lo cual se traduce un feedback más rápido para el desarrollador
  2. Es posible desde las pruebas acceder el estado interno de la aplicación simplificando las tareas de setup (Given/Arrange) y verificación (Then/Assert) de las pruebas

Es importante tener presente que estas dos cualidades pueden traer también algunas complicaciones (pruebas inconsistentes, resultados incorrectos, etc) sino no se toman ciertas precauciones al momento de automatización de las pruebas.

Resulta interesante tener presente que si escribimos nuestras pruebas con cierta precaución en el uso de 2 (o sea: si evitamos acceder el estado interno de la aplicación por fuera de su interface pública) podemos entonces utilizar el mismo set de pruebas para probar la aplicación ya instalada en un ambiente de prueba.

Tenemos entonces dos usos posibles de Cucumber: 

  1. Como herramienta del programador, utilizándola en su máquina local para guiar su desarrollo y obtener feedback instantáneo de la ejecución de los ejemplos acordados con el usuario
  2. Como herramienta para ejecutar las pruebas de aceptación y regresión en un ambiente de prueba, siendo estas pruebas las mismas que el programador utilizo para guiar su desarrollo

Si bien en este caso estoy hablando de Cucumber (ruby) estas cuestiones que menciono también aplican a otros frameworks/tecnologías.

Mientras termino de escribir estas línea me doy cuenta que para entender mejor este tema puede resultar muy conveniente ver algo de código, por ello en los próximos días estaré publicando un video mostrando ejemplos de código.

[*] esto en parte tiene que ver con capacidades de Cucumber pero también con las abstracciones y capacidades de otras herramientas del stack de Ruby como Rack.

Dos estrategias para la adopción de DevOps

Partiendo de la premisa que DevOps viene a intentar mejorar el flujo de software delivery, reduciendo las fricciones entre desarrollo y operaciones, intentando incluso derribar los silos, me he encontrado con distintas estrategias de implementación. De forma muy simplificada he logrado identificar dos patrones recurrentes cuando una organización adopta una estrategia DevOps. A falta de creatividad en este artículo las denominaré “Desarrollo Empoderado” y “Operaciones Serviciales“.

Desarrollo Empoderado

Esta estrategia implica empoderar a los equipos de desarrollo para tomar responsabilidad sobre todo el proceso de delivery. Esto tiene dos implicancias fuertes. Por un lado el equipo de desarrollo incorpora más responsabilidades y habilidades, se involucra con la infraestructura, el pipeline de delivery, etc. Por el otro el equipo de operaciones “suelta” un poquito, comparte más con los equipos de desarrollo a partir de involucrarse en el día a día del proyecto, etc. Incluso en algunos casos una persona de operaciones se suma como un team member más al equipo de desarrollo.

Operaciones Serviciales

En esta estrategia operaciones sigue manteniendo cierta distancia con desarrollo pero a partir de un fuerte trabajo de automatización facilita el día a día del equipo de desarrollo proveyendo una experiencia que podríamos denominar “operaciones como servicio”. En estos casos la visión de operaciones es: “que desarrollo se concentre en las user stories y hagamosle la vida lo más simple posible y que con un par de clicks puedan tener acceso los recursos que necesiten“. Esto requiere obviamente, incorporar habilidades, herramientas y sobre todo proactividad, colaboración y vocación de servicio.

En cierto modo estas dos estrategias, descriptas aquí de forma muy simplificada, pueden ubicarse en dos extremos de un continuo de estrategias que incorporan elementos de cada una.

Personalmente, trabajando en desarrollo, me siento mucho más cómodo con la estrategia Desarrollo Empoderado, pero soy consciente que puede no ser así para todos los desarrolladores y también que en algunas organizaciones puede ser más conveniente una estrategia del estilo Operaciones Serviciales.