Proyecto CMS, día #3

Un día realmente complicado pero para que se entienda debo dar un poco más de contexto del proyecto. Anteriormente mencioné que tenemos varios equipos trabajando en distintos lugares alrededor del globo, pero lo que no mencioné es que cada equipo trabaja en cosas distintas, básicamente cada equipo tiene un subproyecto. La visión global del proyecto es tomar un sitio existente y ponerlo a correr sobre la plataforma CMS. Esto implica varias cuestiones:

  • Agregar a la plaforma CMS algunas funcionalidades faltantes (aquí estoy yo)
  • Estabilizar algunas funcionalidades de la plataforma que hasta el momento no estaban en uso (equipo en India)
  • Migrar la información del sitio “viejo” a la plataforma (equipo en USA)
  • Realizar diversos ajustes a nivel de infraestructura (otro equipo en USA)
  • Realizar varias gestiones a nivel organizacional (por ejemplo el anuncio de prensa)

Todo esto nos lleva a que distintos equipos, trabajando en distintos lugares, en distintas bandas horarias, se encuentren tocando el código de una misma aplicación. Uno podría pensar que usar una estrategia de feature branch podría ser apropiado, pero quienes llevan la batuta del proyecto tienen una postura bastante extrema y se han tomado la cuestión del delivery contínuo muy a pecho. Por ello es que todo el mundo trabaja sobre el trunk utilizando una estrategia de Feature Toggle. Personalmente no me termina de convencer, pero por ahora funciona. Al mismo tiempo, para poder dar soporte a la estrategia de delivery contínuo contamos con una robusta infrastructura basada en Jenkins y Heroku. Tenemos dos ambientes casi identificos corriendo en Heroku: preview y producción. Cada vez que se completa una story, se realiza un depliegue a preview. Por su parte Jenkins tiene 4 trabajos:

  • Integración contínua, se dispara automáticamente en cada commit, ejecuta las pruebas unitarias (Ruby y JavaScript) y verificaciones de código
  • Integración, ejecuta pruebas de integración y se dispara automáticamente luego de cada despligue a preview
  • Depliegue a Preview, se dispara manualmente y como su nombre lo indica, despligue la aplicación y tagguea
  • Depliegue a Producción, se dispara manualmente

La complicación del día se debió a que el equipo estaba trabajando en la migración de datos, probó sus scripts con la base del ambiente de preview y ello generó ciertas inestabilidades en la instancia de preview. La situación se vió agravada porque este equipo no avisó de esto al resto de los equipos. ¿y porque no mencionaron eso en la reunión de standup? Simplemente porque no asistieron, ja!. Para sumar un poco más de tensión a la situación, resulta que en otra parte del globo estaba el cliente probando la aplicación, ja!.

En cuanto se detectaron las inestabilidades, todos los equipos suspendimos nuestras tareas y nos pusieron a ver cuales eran las causas de las misma. Luego de varias verificaciones detectamos que el problema se debía a los datos inconsistentes/faltantes y pudimos resolverlo. Todo este revuelo me costó dos horas. A pesar de eso pude completar mis compromisos del dia y desplegar mis stories al ambiente de preview.

Una vez más ví confirmada mi tesis, el principal factor de éxito de los proyectos, no es una cuestión de técnica, sino humana: comunicación.

Continuará…

Anuncios

4 comentarios en “Proyecto CMS, día #3

  1. Hola Nico, esta serie de posts es muy interesante para ir viendo el día a día de un proyecto que empieza con el pie derecho desde el principio.

    Me intriga qué es lo que no te termina de cerrar de los feature toggles. Los he usado en un par de proyectos y me parecieron una forma bastante sencilla de manejar las cosas “a medio hacer” antes de poder integrarlas definitivamente (aunque no sea super prolijo… tal vez habría que usar un poco de metaprogramación para tener un buen soporte)

    Saludos

    1. Respecto de lo feature toogles, a nivel de código de negocio puede que ande, pero con las vistas (html) me parece que puede llegar a complicarse. Por el momento yo estoy codeando logic de negocio y por ello no me topado con el problema.

      1. Si las vistas se generan server-side (como posiblemente esté pasando), no debería haber demasiado problema… Es un tema interesante para que nos mantengas al tanto 😉

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s