Etiquetado: projectStory
To Heroku or not to Heroku
Hace un tiempo estuve escribiendo sobre el Proyecto CMS. Actualmente continuo trabajando en dicho proyecto y en estos dias estamos analizando en que plataforma hostear la aplicación. En este momento la aplicación está corriendo en Heroku, pero hay ciertas cuestiones que están ocasionando issues de performance. Ello llevó a que hicieramos una prueba de concepto levantando la aplicación en Linode.
Personalmente creo que las cuestiones de performance de la aplicación no tienen que ver con donde está hosteada sino con ciertas cuestiones de diseño y configuración. Al mismo tiempo, el pasaje de una plataforma como Heroku a otra plataforma del estilo Linode o Amazon EC2 implica un incremento importante en el costo de operación (al menos en un principio hasta que uno logra automatizar parte del trabajo).
Estimo que en las próximas dos semanas estaremos tomando una decisión respecto a esto (en realidad yo no tomo ninguna decisión, simplemente doy mi opinión).
Continuará…
Proyecto CMS, Go Live and Next Steps
Hace unas dos semanas, salimos en producción. La parte pública de la aplicación está accesible aqui.
Por estos dias estamos comenzado a trabajar en el siguiente hito: liberar como open source toda la plataforma. Esto me resulta especialmente interesante, pues si bien yo ya he publicado algunos proyectos open source, en general han sido cosas pequeñas. En este caso se trata de un producto de dimensiones interesantes y el cual se espera que tenga aportes de la comunidad. En cuanto tengamos algo publicado, les contaré.
Proyecto CMS, flujo diario de trabajo
Alrededor de las 8 de la mañana, enciendo la máquina, inicio sesión y lo primero que hago es ver las novedades, pues dado que tenemos un equipo en India que trabaja a contrahorario es muy común iniciar el día con noticias de progreso. Entonces abro el cliente de correo y un navegador para loguearme en Campfire, la herramienta de chat colectivo. La ventana de Campfire queda abierta todo el dia. Voy leyendo los correos del proyecto, si es que hay alguno y voy contestando.
Una vez al tanto de las novedades, abro una terminal y actualizo mi repositorio local: git pull. Abro otra ventana del navegador para ver que todo esté en orden en el build server (Jenkins). En otra ventana del explorador abro la herramienta de gestión (Chili).
Con esto ya estoy listo para empezar a codear, inicio Rubymine y manos a la obra.
A las 10 de la mañana, inicio sesión en Vydeo para conectarme a la stand up global del proyecto, la cual dura entre 10 y 15 minutos. Luego inicio GoToMeeting para hablar con mi sub-equipo, esta reunión suele durar un poco más pues hablamos algunas cuestiones de diseño o hacemos troubleshooting de algún impedimento. Al finalizar esta reunión, ya tengo en claro el trabajo de mi dia, asi que envio un mail a la lista de proyecto contando brevemente mis compromisos.
El resto del día transcurre como una seguidilla de Pomodoros interrumpida solamente por 40 minutos para el almuerzo. Dependiendo de las funcionalidades en desarrollo, puede que hagamos una sesión de pair programming usando Google Hangout. Las funcionalidades en general las desarrollo haciendo TDD. Cada vez que termino una funcionalidad, corro todas las pruebas unitarias (que son alrededor de 1500) y si todo está bien, subo el código al repositorio común lo cual dispara el proceso de integración. Si la integración es exitosa, entonces disparo un despligue a al ambiente de preview para que quien guste pueda ver la nueva funcionalidad agregada. Finalmente actualizo el estado de la funcionalidad en la herramienta de gestión.
Si la funcionalidad desarrollada requirió algún cambio de impacto relevante en el resto de la aplicación (un cambio en la base de datos por ejemplo) envio un mail a la lista de proyecto avisando de esto y si corresponde también documento el tema en la wiki del proyecto.
Al final del día, envio un mail a la lista de proyecto resumiendo el estado de los compromisos asumidos para el día y comentando también mis siguientes pasos.
Proyecto CMS, día #17 – Fin
Era el gran día: la salida en producción, pero no fué. El producto está listo, ha pasado las pruebas, pero el cliente ha decido posponer la salida en producción por cuestiones de negocio.
De forma simplificada podemos decir que el sistema construido reemplaza a un sistema existente y que en este momento el negocio está cerrando un ciclo. El cliente ha considerado conveniente que el ciclo de negocio actual se complete con el sistema “viejo” y recien poner en funcionamiento el sistema nuevo al finalizar el ciclo. Dado que el ciclo de negocio termina la semana próxima, el aplazo de la salida en producción no debiera ser mayor a una semana.
Más allá de esto, mañana haremos el cierre formal del release.
Dado que estamos cerrando una etapa, es un momento apropiado para hacer un retrospectiva, pero resulta un contexto un tanto complejo dada la distribución del equipo. Asi que siguiendo la recomendación de @jgabardini, he propuesto que cada sub-equipo haga su propia retrospectiva y luego compartamos los resultados y coordinemos los action items.
De ahora en más ya no escribiré los avances diarios, sino sólo los hechos relevantes como la salida en producción, los resultados de la retrospectiva, etc.
Espero hayan disfrutado de este relato de un proyecto real. Fin.
Proyecto CMS, día #14
Comencé el dia hablando con el equipo de Chennai sobre como manejar una situación excepcional en el flujo de la aplicación. ¡Durísimo! ¡Como me cuesta entender el acento de la gente de India hablando en inglés! Definitivamente es el acento más dificil que me ha tocado interactuar. Siguiendo la buenas prácticas, al final de la reunión mandaron un mail con la conclusión de lo hablado y lo cual me permitió confirmar que a pesar de la dificultad de comunicación, había entendido bien.
Con el output de la reunión logramos completamos la funcionalidad faltante, arreglamos los test rotos y mergeamos nuestro branch con el master.
Ahora, test, test, test y producción y más allá.
Continuará…
Proyecto CMS, día #13
Un día normal, sin certeza de la fecha de salida en producción, pero al parecer la funcionalidad que estoy desarrollando determinará la fecha en cuestión. Hice un progreso interesante en el desarrollo de esta funcionalidad, solo faltaría agregar un buen manejo de excepciones y arreglar algunas pruebas que se rompieron y no entiendo porque pues no parecen tener relación con el código agregado/modificado.
Tuve algunos aprendizajes interesantes en lo que respecta a diseño, ya les dedicaré algún post futuro.
El lunes es feriado en USA, con lo cual, si todo va bien, el usuario realizaré las pruebas el martes y si todo está bien saldremos en producción el miércoles.
Continuará…
Proyecto CMS, día #12
La gran novedad del dia fue que el cliente decidió que la funcionalidad que estaba desarrollando yo, que estaba planificada para el siguiente release, debe ser incluida en este release, aunque eso implique retrasar la fecha de release, ¡ja!. Otro punto relevante es que tuve contacto directo con uno de los usuarios, si!!!!!!!!!
Proyecto CMS, día #11 (feature branch)
La demo de hoy estuvo dedicada a revisar la lista de issues. La buena noticia es que se estableció la fecha de release para el Lunes, pues los fix vienen bien y al mismo tiempo se destrabaron las cuestiones administrativas respecto del servicio de pagos.
Por mi parte comencé a trabajar en una funcionadad del siguiente release y para eso cree un feature branch en lugar de usar la estrategia de feature toogle. La razón de esto es que la nueva funcionalidad “colisiona” con una funcionalidad actual del sistema y varias modificaciones son necesarias, con lo cual usar feature toogle sería un caos por la cantidad de código adicional necesario agregar para el toogle.
Continuará…
Proyecto CMS, día #10 (ja!, se puso picante)
No vamos a salir en producción mañana. En primer lugar porque el servicio de pago utilizado para las donaciones no ha sido activado por ciertas cuestiones “contractuales”.
Más allá de eso, logré tener acceso a los resultados de las pruebas realizadas ayer por los usuarios. Hay más de 20 issues reportados pero ninguno relacionado a nuestras funcionalidades ¿curioso no?. En realidad no tanto, resulta que como el ambiente de pruebas estaba andando muy lento, alguien decidió que los usuario hicieran las pruebas directamente sobre el ambiente productivo, pero nadie se tomó el trabajo de aplicar ciertas configuraciones necesarias para nuestras funcionalidades, con lo cual las mismas no pudieron ser probadas ya que fallaban en el primer click, ja!
¡La bronca que me agarré!, porque yo mismo habia mandado un mail a la lista de proyecto hace un par de dias con los detalles de configuración que era necesario aplicar en el ambiente de producción antes de pretender usar las nuevas funcionalidades. Y no es algo que mencioné a la pasada, sino que era un mail dedicado exclusivamente a esta cuestión.
Respecto de mi trabajo de hoy, tuve unas cuantes reuniones, hicé algunos ajustes menores a funcionalidades existentes, ajusté la configuración del ambiente de producción y empecé a trabajar en el diseño de una funcionalidad del siguiente release.
Continuará…
Proyecto CMS, día #9
El foco de hoy estuvo en las pruebas de usuario. No tuvimos reportes de errores sobre las funcionalidades desarrolladas por nuestro equipo, pero puede que se deba a que no llegaron a probarlas, lamentablemente no tenemos suficiente visibilidad al respecto.
Lo que sí supimos es que hubo algunos issues de infraestructura (errores de memoria) pero aún no leí el reporte en detalle.
Más allá de esto, hoy trabajé en implementar una funcionalidad que estaba planificada para el siguiente release, pero que por un cambio de prioridad tuvimos que adelantarla. También empecé a trabajar en el diseño de otra funcionalidad de alta prioridad de la siguiente iteración.
Mañana voy a meterme a analizar los errores de infratructura que fueron reportados hoy.
Continuará…