Mes: enero 2017

El equipo de DevOps

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.

infra_pattern

Convocatoria de autores para el libro del AOC 2017

Como ya mencioné hace un tiempo, este año quiero editar el tercer libro de la colección AOC para así completar la trilogía.

Dado que este año habrá 2 AOC (por cierto esta semana comenzó el proceso de inscripción/postulación para el AOC de Chile) mi idea es que el libro contenga capítulos de autores participantes de uno y otro AOC.

La dinámica de escritura será igual a los casos anteriores, en el sentido que serán capítulos independientes pero respetando una estructura mínima. En cuanto a la consigna, la idea es escribir ensayos/reflexiones/opiniones.

Dicho todo esto, abro la convocatoria de autores para este tercer libro. Los requisitos son simples: participar de al menos uno de los AOC 2017 y comprometerse a entregar el capitulo «release candidate» un semana antes del AOC en que se piense participar.

A los interesados en sumarse a esta iniciativa les pido que por favor:

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.

devops_book_sei

Estadísticas personales 2016

Desde que comencé a trabajar en forma independiente registro con bastante detalle el tiempo que dedico a mi actividad profesional y dado que me gustan las estadísticas y el cierre de año parece un momento propicio para actualizarlas.

Durante 2016 hice un cambio relevante en la utilización de mi tiempo motivado principalmente por tomar un cargo de mayor dedicación en la Universidad. Analizando mi registro de horas los números indican que mi dedicación industria/academia fue 60/40.

2016_industria_vs_academia

Del análisis se desprende también que el promedio de horas trabajadas semanalmente (industria + academia) suma 32 horas semanales. Aquí hay algunos puntos a tener presentes:

  • El trabajo en la academia tiene «pozos y picos», por ejemplo durante enero/febrero la actividad es muy baja debido a que no hay clases, mientras que durante diciembre y julio/agosto suele haber picos debido al cierre de cuatrimestre.
  • Las horas aquí contabilizadas del trabajo en la industria son solamente las horas facturables. Cuando uno trabaja en proyectos de desarrollo el total de las horas dedicadas son facturables, pero cuando los proyectos son de consultoría/capacitación hay algunas horas que no se facturan (típicamente las dedicadas a la pre-venta)
  • No están reflejados en el registro de horas las cuestiones de «formación, marketing y similares», o sea: los cursos, conferencias y charlas a los que asistí, ni tampoco las lecturas ni las katas que realicé, ni mucho menos el tiempo dedicado a pre-venta, ni a escribir en este blog, ni tampoco los cursos que armé y dicte en empresas. Al mismo tiempo cabe destacar que muchas de estas actividades no son exclusivamente académicas ni industriales pero sin embargo aportan a ambas dimensiones ya que en mi caso particular ambas dimensiones están enfocadas en la misma área de conocimiento: ingeniería de software.

En base a lo puntos anteriores se desprende que en realidad dedico más de 32 horas promedio por semana a mi actividad profesional, la pregunta que surge entonces es: ¿cuantas horas trabajo por semana? La respuesta no es trivial, como indica un viejo dicho «búscate un trabajo que te apasione y no trabajarás nunca más«, puede sonar a chiste pero es mi realidad. De todas formas quiero intentar dar una respuesta a esta pregunta. En términos generales dedico a mi actividad profesional el horario típico de oficina o sea de lunes a viernes de 9 a 18, a excepción de los martes por la mañana y viernes por la tarde que intento dejarlos libre.  Pero al mismo tiempo dos veces por semana dicto clases en la universidad después de las 18. Finalmente los sábados por la mañana por la mañana también los dedico a cuestiones profesionales, generalmente lecturas relacionadas a mi proyecto de investigación. Con lo cual en términos generales dedico unas ~44 horas a cuestiones profesionales, lo cual implica unas ~12 horas típicamente no facturables directamente que suman tanto a mi actividad profesional como académica.

distribucion

Al analizar las tecnologías con las que he trabajado en este 2016 se destaca .Net, cosa que no ocurría desde 2013.

distribucion_tecnologias

 

Finalmente en lo que respecta conferencias/eventos/cursos:

  • Participé en 5 conferencias grandes, cuatro de ellas internacionales
  • Participé de  6 cursos (sin contar las sesiones de las conferencias)
  • Dicté/facilité 12 cursos/charlas

Finalmente en lo que respecta a este blog, escribí 101 artículos, prácticamente 1 cada 3 días.

Mirando en retrospectiva y comparando con años anteriores este 2016 fue un año muy intenso y el pronóstico para 2017 (al menos en los primeros meses) pinta muy parecido.