Optimizando el pipeline de deployment

Esta semana empezamos a trabajar con @CodeRaguet y Maxi Cruz en la tarea de optimizar el pipeline de deployment. Actualmente tenemos un pipeline de deployment que hace lo siguiente:

  1. Ante cada cambio en el repositorio obtiene el código
  2. Compila y corre las pruebas unitarias
  3. Despliega a un ambiente que “de integración”
  4. Corre las pruebas de aceptación
  5. Publica los artefactos
  6. Publica los pactos (pact)
  7. Despliega a un ambiente “de demo” donde la aplicación queda disponible para pruebas manuales

La ejecución de este pipeline insume actualmente ~45 minutos y el ~85 % de ese tiempo de ejecución lo consume el paso 4: la ejecución de los tests de aceptación.

Este pipeline representa la primera parte del camino hacia producción y se ejecuta varias veces al día ya que el equipo hace trunk-based development (todos trabajan en master). A continuación de este pipeline hay otro que se dispara manualmente que cubre los ambientes de tests y producción.

Un detalle no menor de esta situación es que si no hacemos nada esta situación va a empeorar gradualmente porque el producto está en constante evolución y todo el tiempo se van a agregando nuevos tests.

El desafió que enfrentamos es reducir el tiempo que insume este pipeline y por ende el tiempo que insume la ejecución de las pruebas aceptación. La estrategia que vamos a intentar implementar es: segmentar los tests de aceptación por grupos de funcionalidades y luego ejecutar cada grupo en paralelo.

En una semana les cuento como nos fue.

Cierre MeMo2 2019-1

Se fue un cuatrimestre más y es momento de análisis. Comencemos por los fríos números:

  • 32 inscriptos (34 formalmente pero 2 nunca asistieron a clase)
  • 3 abandonos antes de la sexta semana
  • 23 alumnos completaron la materia con promoción
  • 5 alumnos pendientes de final
  • 19 tareas individuales (11 cuestionarios y 5 ejercicios de programación)
  • 2 TPs grupales
  • 1 visita de la industria
  • Evaluación general de la materia: 8.9 (según encuesta interna)
  • Opinión general de la materia: 4.6 (según encuesta del departamento)
  • Claridad de los docentes (según encuesta interna): 4.8 / 5
  • Conocimiento de los docentes (según encuesta interna): 4.9 / 5
  • Dinámica de clases (según encuesta interna): 4.5 / 5
  • Materiales de estudio (según encuesta interna): 4.3 / 5
  • Dedicación promedio extra clase (según encuesta interna): 8 hs. semanales

Por otro, más allá de los números la sensación es muy positiva. Basado en el feedback recibido tanto en las encuestas como en las retrospectivas creo este resultado es consecuencia de 3 puntos destacados:

  • Un cambio de orden en los temas de la materia poniendo más foco inicialmente en cuestiones de programación. Esto a mi parecer facilitó en entendimiento de los temas de proceso y el desarrollo de los TP grupales.
  • La incorporación de ex-alumnos al equipo docente. Si bien una ex-alumna había colaborado en algunas cuestiones el cuatrimestre anterior, esta vez con contamos con varios ex-alumnos que colaboraron a lo largo del todo el cuatrimestre.
  • La temática del TP final que incluyó el desarrollo de un Bot de Telegram. Creo que esto generó cierta motivación entre los alumnos.

No están en la foto los ex-alumnos que participaron como colaboradores: Jessica, Josefina, Anarella, Facundo, Pablo y Martín.

Experimento consultorio

Experimento consultorio

Hace un tiempo me contactó un directivo de una organización para que ayudara a mejorar cuestiones de calidad en sus equipos. Pero a mi parecer los equipos no estaban tan interesados en mejorar esos aspectos que me planteaba el directivo. Me pasó varias veces que luego de haber acordado reunirme con un equipo, me cancelaron a último momento. Es así que luego de un par de actividades (algunas de ellas fallidas) acordamos comenzar esta semana con un nuevo experimento: el consultorio.

La idea es simple: yo voy a estar recurrentemente una tarde por semana en las oficinas de este cliente para atender consultas de sus equipos. Esas horas recurrentes son take or pay, o sea: se cobran haya o no consultas. Esto pone “cierta carga” del lado del cliente en generar consultas/actividades para que esas horas efectivamente se utilicen. Por mi parte, este esquema me permite planificar mi tiempo sin correr el riesgo de “perder horas” por cancelaciones de último momento.

Si este esquema funciona ese espacio de consulta debería disparar acciones concretas dentro de cada equipo. Si la cuestión no puede resolverse en el tiempo de consulta entonces agendariamos sesiones adicionales.

Sinceramente no estoy muy convencido esto vaya a funcionar pero bueno, es un experimento, sino al cabo de un par de semanas no funciona, se ajusta o se cancela.