El equipo de DevOps

Como mencioné anteriormente ya estamos en producción y dado que el cliente no tiene un area de sistemas está acordado que nosotros mismos nos encarguemos de la operación. Para esto armamos el equipo «DevOps», y para ser sincero debo admitir que inicialmente el nombre no me cerró, yo lo habría llamado directamente «operaciones». Pero creo que la intención al llamarle «DevOps» fue ya desde el nombre intentar transmitir el mindset con el que se quiere trabajar. En fin, en punto del nombre no es tan relevante. Creo que lo interesante es la forma en que estamos intentando trabajar. En este momento somos 3 personas:

Una persona con skills de operaciones/sysadmin y automatización (en particular usando Chef)
Una persona proveniente del equipo de UI (js/html/css)
Una persona proveniente del equipo de desarrollo server-side (C#). Este soy yo, que adicionalmente estoy oficiando de «facilitador» del equipo

Para la coordinación/organización del equipo estamos usando las siguientes herramientas:

Una lista de correo
Un canal de Slack
Un tablero Kanban (en Jira)

Respecto de la dinámica de trabajo, trabajamos en un flujo continuo, limitando el work-in-progress e intentando planificar semanalmente. En este sentido cada lunes reportamos los items completados la semana anterior e identificamos los items más prioritarios para trabajar en la semana actual. Luego con el correr los días se van sumando a nuestro backlog nuevos items que debemos atender en forma inmediata. En todos los casos estos items «urgentes y no planeados» los registramos en el Jira para que quede constancia de nuestro trabajo.

Respeto del tipo de tareas que realizamos, en este momento tenemos 3 hilos de trabajo principales:

Automatizar el provisionamiento de toda nuestra infraestructura
Armar la arquitectura de build y el pipeline de deployment
Atender pedidos puntuales de los equipos de desarrollo (por ejemplo asistir a un equipo en la configuración de alguna herramienta cuya configuración aún no está automatizada)

Un punto que puede resultar curioso es que este equipo de operaciones no se encarga completamente de la operación, al menos no por ahora. En este momento tenemos una solo aplicación en producción pero es el equipo que la desarrolló quien la monitorea y atiende eventuales alertas.

Por el momento me gusta la forma en que esto está fluyendo, pero recién empezamos, ya veremos como evoluciona.

projifm: Estadísticas del primer release

Finalmente la semana pasada salimos a producción. El evento en cierto modo fue muy tranquilo ya que nuestra aplicación estaba instalada y funcionando en el ambiente productivo desde hacía varias semanas.

Comparto aquí algunas estadísticas:

Estadísticas de proceso

7 iteraciones (2 semanas cada una) con un equipo de 5 ingenieros
6 semanas de trabajo «on-demand» de un ingeniero monitoreando y realizando ajustes menores
313 items de Jira resueltos

Estadísticas de código

(esto números son específicos del nuestra aplicación, pero el equipo también trabajó sobre componentes compartidos con otras aplicaciones que no está considerados aquí)

138 test automatizados
83.5% de cobertura
67 clases (sin contar las clases de tests)
7329 líneas totales de código
4211 líneas de código productivo (57%)
3118 líneas de código de tests (43%)

Deuda técnica
Al momento de este primer release registramos los siguientes items de deuda técnica:

Código duplicado en los tests
Dependencias externas desactualizadas
Falta de monitoreo más granular de ciertos componentes

PCE-Evolution: An infrastructure pattern

Beyond which environments I use on different project/organisation there is one recurrent strategy that I have applied several times in different context. I may say it is a pattern.

The problem

Like any pattern explanation it should start with a problem, so here it is: it is very common production environments to be large in term of hardware capacity and also in size of data. This makes difficult (and/or very expensive) to replicate the production environment to test your application. If you test in an environment different from the production environment you are taking a risk, and the bigger the difference is the higher the risk you are taking.

The solution

Your application pass through different environments from you local development machine to the final production environment. These two environments are the extremes of your pipeline, so you should make use that each intermediate environment is «closer» to the production environment.

Example

Local development environment (your workstation): here you run the whole application in an isolated way, you have a local DB installed and external services dependencies may be mocked. Your hardware is not comparable to production’s hardware. Even your OS may be different: you may use Windows 10 or Mac or Ubuntu Desktop, while your production server may run Windows Server or Ubuntu Server. In terms of the previously mentioned dimensions, all of them are different from production.

Development environment: your hardware is still far from production, but at least you have the same OS asp production but the other dimensions are still different.

Test Environment: here your layout is the same as production, that is: if you have a cluster for the production DB, then you also have a cluster for test DB but possibly your test DB cluster has less servers that the production one.

This way the closer to production the more Production-like, Complex and Expensive.

Una visión formal/académica sobre DevOps

Ayer por la tarde «me interné» en un local de Barnes&Noble y recorriendo la sección de libros de tecnología me encontré con un libro cuya existencia desconocía: DevOps, a Software Architect’s Perspective de Len Bass y Cía.

Apenas leí el índice no dudé ni un instante en comprarlo ya que es el primer libro que veo sobre esta temática de una fuente «formal/académica» como es el SEI-CMU.

Anoche empecé a leerlo y por el momento pinta muy interesante.

Agile Open Camp 2017

El año próximo habrá dos Agile Open Camps, «el tradicional» en los alrededores de Bariloche (marzo) y otro en las afueras de Santiago de Chile (mayo).

Ayer un colega me preguntaba sobre esta conferencia: «¿qué tiene de distinto?»

En primer lugar lo referí a los artículos que escribí sobre el AOC en mi blog. Y luego le conté que lo más interesante a mi entender era la experiencia de participar más allá del contenido de la conferencia. A nivel contenido, creo que el evento es principalmente de índole «soft», son muy pocas las sesiones de índole técnica y al mismo tiempo son muchas las sesiones que ni siquiera tienen que ver directamente con desarrollo de software. De todas formas como el evento es en formato Open Space, cada uno puede proponer las sesiones que guste. Algo que me resulta distintivo de este evento es la posibilidad de generar entregables concretos que trasciendan la conferencia. Esto se debe a que todos los asistentes estan alojados en el mismo lugar, compartiendo mucho tiempo y con la completa libertad que brinda un open space. En las dos ediciones anteriores yo mismo me encargué de la edición de dos libros que escribimos durante la conferencia. Para esta edición 2017 me gustaría trabajar en el tercer libro o bien en alguna pieza de software.

Esta semana comenzó el proceso de postulación para el AOC de Bariloche: http://argentina.agileopen.camp/, yo ya hice mi postulación ¿y vos?

Cierre de Ingeniería de Software en UNTreF

El cuatrimestre terminó y si bien no todo salió perfecto, estoy conforme con el resultado.

Una cuestión fundamental a mi entender para el buen fluir del cuatrimestre es que este mismo grupo de alumnos cursó conmigo el cuatrimestre anterior la materia Análisis y Diseño Orientado a Objetos. En dicha materia hicimos un gran foco en cuestiones técnicas de ingeniería de software lo cual permitió que en esta materia podamos poner más foco en las cuestiones no tan técnicas.

Comparto aquí algunos puntos destacados:

10 inscriptos, 10 aprobados
La nota promedio de cierre de cursada fue 9
La evaluación general de la materia realizada por los alumnos (vía encuesta anónima) fue 8,4
El tiempo promedio semanal dedicado por los alumnos fuera de clase fue 8 horas.
Tuvimos dos clases especiales a cargo de invitados: Sergio Villagra nos visitó para dar la clase de modelos de calidad y Emilio Gutter vino a contar la forma de trabajo y organización de 10 Pines
La actividad de cierre de la materia (lecciones aprendidas) fue facilitada por también por Emilio Gutter.

DevOps se busca ¿como sería tal cosa?

Desde hace un tiempo estamos en la búsqueda de una persona con perfil «DevOps» lo cual para algunos resulta imposible ya que tal perfil no existe ¿¡!?.

Uno de ellos es mi colega @carlospeix con quien mantuvimos una muy entretenida charla ayer por la tarde al respecto de este tema. Coincido completamente con la visión de Carlos: DevOps no es un rol sino un mindset, una forma de colaboración entre entre las áreas de desarrollo y operaciones, un estrategia distinta para realizar las tareas que típicamente atañen a estas áreas.

Sin embargo muchos ven «DevOps» como un perfil, lo cual puede apreciarse con una simple búsqueda en LinkedIn donde uno encontrará miles de profesionales etiquetados como «DevOps». Bueno, ponele que sí, que DevOps es un perfil entonces ¿que habilidades, capacidades y conocimientos debería tener una persona con este perfil?

En primer instancia el término sugiere una mezcla de desarrollo y operaciones, de developer y sysadmin. Alguien que debería poder construir una aplicación, ponerla en un ambiente productivo y operarla. Si, en principio es eso lo que yo esperaría de mínima, pero también algo más. Esperaría una persona con muy buenas habilidades de comunicación y facilitación.

Curiosamente, la gran mayoría de CVs de DevOps que me visto mencionan una larga lista de herramientas, pero poco dicen de las llamadas «habilidades blandas». Y algo similar ocurre con los avisos de búsqueda de DevOps que he visto publicado por muchas organizaciones.

En fin, volviendo al tema original, estamos buscando un profesional con los siguientes conocimiento/habilidades:

Administración de ambientes Windows
Administración de ambientes AWS
Programación en .Net / C#
Programación con alguna herramienta automatización (Chef, Ansible o similar)
Muy buena comunicación
Habilidades interpersonales
Lean / eXtreme Programming / Scrum
Idioma inglés

Interesados no duden en contactarme.

Crowdfunding de conferencias, algunas ideas al respecto

Ayer vi un tweet de @Pablitux en que decía que estaban buscando ideas de Crowdfunding para el AOC 2017. Pensé en contestarle en privado pero instantáneamente me di cuenta que estas ideas podían ser de interés más general, así que aquí van.

Catering: tradicionalmente en las conferencian el catering (coffe breaks, almuerzos, etc) están a cargo de la organización. Pero curiosamente en los Agiles Argentina hemos experimentado exitosamente con catering auto-organizado. En sentido se me ocurre que se podría aplicar algo similar. Tal vez puedan conformarse distintos equipos donde cada uno se encargue de preparar alguna comida para todos los asistentes.

Libro: al igual que en las dos ediciones anteriores para esta tercera edición también tengo planeado escribir un libro. Entonces se podrían vender ejemplares físico de ese libro (la versión digital es gratuita en el caso del AOC). Más aún se podrían armar distintos paquetes que incluya también los libros de las ediciones anteriores.
Merchandising: el logo del AOC con los 3 monitos con antejos de sol tiene «mucho punch». Se me ocurre entonces que se podrían vender «elementos» lookeados con este logo de los monitos por ejemplo remeras (playeras/camisetas) y/o pegotines (calcomanias),
Actividades: creo que podría ser interesante para algunos asistentes maximizar la inversión de asistir al AOC. En ese sentido se me ocurre que se podría ofrecer a los asistentes algunas actividades extra en días previos o anteriores a la conferencia las cuales podrían generar cierta ganancia para la organización del evento. En concreto se me ocurren 2 opciones:
- turismo: la organización de la conferencia podría realizar algún tipo de acuerdo con alguna agencia de turismo para ofrecer actividades a los asistentes y al mismo tiempo ganar una comisión
- cursos: lo explico en primera persona porque me resulta más fácil pero creo que es extrapolable a otras personas. Yo suelo dictar talleres/cursos como parte de mi actividad profesional. De cara a colaborar con la organización del AOC estaría dispuesto a dictar uno de mis talleres y donar un % importante de lo recaudado para la organización del AOC (incluso dependiendo del caso podría donar 100%). Obviamente la organización de AOC debería encargarse de la logística y venta de estos cursos.

Creo que todas estas opciones podrían ayudar a financiar el evento y disminuir el costo de la conferencia o mejorar en cierto modo la experiencia de los participantes.

.Net Core: lo que MS no te contó

Si uno se pone a investigar sobre .Net Core encontrará que en la mayoría de las fuentes se destacan las siguientes cuestiones:

La posibilidad de correr de fuera de Windows, más concretamente en Linux y Mac.
La nueva .Net Standard Library y su objetivo de «unificar» el mundo del desarrollo .Net proveyendo verdadera portabilidad entre las distintas plataformas .Net.
La intención de tener un sistema mucho más modular, basado en la idea de un Core realmente pequeño y la capacidad de cargar módulos adicionales según se requiera, usando el gestor de paquetes NuGet.
Una nueva experiencia de usuario para el desarrollador basada en un nuevo set de herramientas en el que se destaca Visual Studio Code.

Si bien considero que todos estos puntos son muy relevantes, creo que el primero tiene un impacto grandísimo pero que curiosamente no parecer estar proporcionalmente publicitado. Por lo que vengo leyendo la capacidad de correr fuera de Windows «es vendida» desde el punto de vista de desarrollo: «ahora podes codear .Net en Linux». Pero a mi me parecer el mayor impacto de esta nueva capacidad no es tanto en desarrollo como en operación/producción, o sea: es posible hacer aplicaciones .Net y ponerlas a correr en un ambiente productivo Linux.

Tal vez esto no sea precisamente lo que más le interesa a Microsoft del nuevo .Net, pero definitivamente es lo más me interesa a mi 😉

Algunos pensamientos sobre deportes, deportistas y habilidades

Cada deporte tiene un conjunto de reglas y un conjunto de técnicas/fundamentos para su práctica. Tomemos el ejemplo del tenis: una regla dice que hay dos oportunidades para ejecutar el saque. Al mismo tiempo existen diversas técnicas concretas para ejecutar el saque y que están determinadas en base un conjunto de cuestiones como ser: a la forma de lanzar la pelota, la posición de los pies, la flexión de las rodillas y el movimiento del brazo, muñeca y raqueta. En base al dominio de las reglas y las técnicas es posible distinguir distintos niveles de «habilidad» de los jugadores:

Autodidacta: en general conoce las reglas, pero su dominio de la técnica es limitado, en general porque no tuvo un entrenamiento formal o bien porque con el entrenamiento que tuvo no logró el completo dominio de la técnica.
Federado: el término obedece al hecho que ha participado (y/o participa) representando a alguna institución (club o escuela) en una competencia perteneciente a una federación/asociación. Ha recibido ha cierta instrucción sobre las técnicas y las reglas, conoce y domina hasta cierto punto (o está aprendiendo a dominar) la técnica. La principal diferencia con el autodidacta es la formación.
Profesional: es un federado pero con una habilidad mayor en el sentido que domina mejor la técnica y al mismo tiempo conoce más técnicas. Tiene una gran preparación física y en general la práctica del deporte es su medio de vida.

Al pensar en esta clasificación veo cierta similitud con el concepto Shuhari proveniente de las artes marciales y que Alistair Cockburn extrapoló al mundo del Software. Sin embargo creo que el mapeo no es directo. El nivel shu incluiría a los autodidactas y también a los federados principiantes, mientras que el nivel ha incluiría a los federados avanzados y finalmente el ri podría incluir a los profesionales.

Durante mi adolescencia practiqué varios deportes con distinto nivel de intensidad y «habilidad»: fútbol, voley, handball, tenis, paddle y basket. Si bien recibí cierta instrucción en todos ellos, solo en el caso de basket llegué al nivel federado. Hoy en día sigo practicando basket y si bien mi estado físico es bastante más pobre que en mi adoslescencia creo que mi manejo de los fundamentos persiste igual. Como suele decirse en me barrio «uno nunca se olvida como andar en bicicleta«.

Blog de NicoPaez

Ingeniería de Software, Docencia y Programación

Categoría: opinion