How to work with blueprints without losing your mind

Cómo trabajar con blueprints sin perder la cabeza

Esta última semana fue bastante ardua para todos los que contribuimos a OpenStack. Dentro de unos días se alcanza la última meta de la serie Grizzly y toda la comunidad estuvo trabajando muy duramente para que esta versión sea tan buena como las anteriores.

Release Cycle: Grizzly

¡A debuggear se ha dicho!

Además de arreglar bugs que solucionan problemas conocidos, mejoran la usabilidad y la experiencia de usuario, uno de los objetivos centrales a la hora de lanzar una nueva versión es agregar funcionalidad.

Y es justamente eso último sobre lo que les voy a contar hoy.

¿Qué son los blueprints?

Un blueprint es una simple especificación que describe una idea, como puede ser una nueva funcionalidad o proceso, y registra información para mostrar en qué estado de implementación se encuentra y quienes están involucrados.

Son usados para organizar y mantener un registro completo de la implementación de nuevas funcionalidades ya que proveen una forma de manejar los lanzamientos de forma ordenada, desde las primeras ideas hasta la implementación.

Con muy poco esfuerzo puede crearse un mapa de ruta que fomenta las contribuciones y establece las mejores ideas para próximos lanzamientos.

Cinco W (y una H) para trabajar con blueprints

¿Qué?
¡Trabajar con blueprints!

¿Por qué?
Porque todos queremos nuevas funcionalidades :)

¿Quién?
Cualquier persona que sienta que se debe agregar una funcionalidad y desee contribuir.

¿Cuándo?
En cualquier momento del ciclo de desarrollo.

¿Dónde?
OpenStack usa Launchpad como plataforma de desarrollo colaborativo y cada proyecto tiene su página. Según el proyecto en el que se encuentren trabajando, deberán acceder a https://blueprints.launchpad.net/-nombredelproyecto-. E.g. https://blueprints.launchpad.net/horizon.

¿Cómo?
Se necesitará especificar un nombre y una descripción de la nueva implementación que se desea realizar. Mientras más consisa sea la descripción, mejor… de ser necesario se puede agregar un vínculo que tenga mayor detalle.

Cuando eso esté listo, se procede a indicar quién lo debe aprobar – el Project Team Leader (PTL) del proyecto -, quién estará asignado al desarrollo, para qué serie se propone y en qué meta se cree que la implementación estará lista.

La persona que se encargará del desarrollo puede ser definida después, y cualquiera puede voluntariarse para hacerlo.

A partír de allí, el PTL aprueba la propuesta, lo asigna a la serie y le establece una prioridad.

En este momento la persona asignada podŕa empezar a implementar y asegurarse de mantener la entrada del blueprint al día. Luego de mucho trabajo y con algo de suerte, el blueprint será integrado a la serie que se había programado.

\o/ ¡A celebrar!

Caso de estudio: Tenant Deletion Workflow

jigzaw

Como parte del proceso de aplicación para el OPW tuve que indicar en qué iba a estar trabajando durante mi pasantía. O por lo menos una buena parte de ella.

Con la ayuda de Julie (jpich) pude encontrar un blueprint que se ajustaba en cierta forma a mi experiencia como desarrolladora y a el tiempo con el que contaba.

Este blueprint, llamado Tenant Deletion Workflow, tiene como objetivo implementar la eliminación de proyectos desde Horizon asegurando que no quede ningún servicio inaccesible, consumiendo recursos y haciendo el sistema propenso a errores.

Si son desarrolladores sabrán apreciar qué tan complicado puede ser la eliminación de una entidad, más si esa entidad involucra muchas variables como en este caso son instancias de VMs, volúmenes, contenedores de objetos, redes y usuarios – por solo decir algunas -. Una mala jugada puede hacer que el usuario pierda datos, o dejar el sistema en un estado inestable. En fin… ¡hay que tener mucho cuidado al borrar cosas!

Cuando ví qué era lo que tenía que implementar me sentí como cuando uno arma un rompecabezas muy grande. ¿Por dónde empezar?

Investigación

Lo primero que debe hacerse al embarcarse en un proyecto que saben, o presienten, que va a tomarles mucho trabajo es investigar el contexto.

Analizar cómo es el estado antes y después de realizar una acción es muy importante para entender qué trabajo debe hacerse y evitar errores.

En mi caso tuve que involucrarme desde cero con el proyecto, por lo que me demoró más tiempo que lo usual. Fui recorriendo API por API, anotando aquellos recursos que tuvieran relación directa con los proyectos. A partir de eso, me sumergí en la documentación oficial para entender un poco mejor su funcionalidad.

Además tuve el apoyo de muchos contribuyentes que pasaron por allí y quisieron dejar sus sugerencias en el whiteboard, dándome buenas ideas y ayudándome a aprender un poco más sobre el entorno.

El resultado fue un completo resumen de qué es lo que debe considerarse en la implementación. Pueden ver más detalles del mismo en el whiteboard del blueprint.

Planeamiento

Con la información que pudieron obtener durante el período de investigación tendrán un punto de partida, pero siempre es conveniente organizarla y dividir el progreso en pequeñas metas. Divide et impera, regla del pulgar que los desarrolladores aprendemos y que luego aplicamos a todos los ámbitos de nuestra vida.

Decidí dividir el trabajo por servicios – Nova, Swift, Glance, Keystone, Neutron y Cinder -, atendiendo todos aquellos asuntos que pude vislumbrar durante la investigación. Además, tambíen separé la implementación en dos versiones: V1 es una implementación sencilla que se encarga únicamente de hacer una limpieza completa y V2 agrega la posibilidad de que el usuario decida qué hacer con cada servicio.

Dado que Horizon es una interfaz de usuario, también tuve que encargarme de bosquejar cómo se iba a ver mi implementación. Con la ayuda de un excelente diseñador de interacciones logré realizar una primera versión de esta interfaz.

Tenant Deletion Workflow UI: Menú de ProyectosTenant Deletion Workflow UI: Confirmación de eliminación para v1Tenant Deletion Workflow UI: Confirmación de eliminación para v2

Implementación

Siguiendo las metas establecidas tendrán que ir involucrándose con el código y construyendo la funcionalidad. Creen un nuevo branch para su trabajo, que deberán llamar bp/-nombre-bp-. En mi caso, git checkout -b bp/tenant-deletion.

Es importante ir implementando, documentando y probando en cada paso para evitar obtener un monstruo de código imposible de debuggear.

Es fundamental mantener el estilo y la prolijidad del código, tómense en tiempo en asegurar este punto. En estos proyectos trabajan muchísimos programadores y es importante la legibilidad y la fácil comprensión del mismo.

Piensen en todo el trabajo de investigación que tuvieron que hacer antes de empezar a implementar y escriban el código como a ustedes les hubiese gustado leer.

Ahora, consideren todo el trabajo que tienen que hacer en esta etapa y calculen el tiempo que le van a destinar. ¿Listo? Bueno, a eso súmenle por lo menos una semana más.

En la etapa de implementación es muy fácil encontrarse con trabas y que eso los demore más de lo usual. Además, algunas tareas que ustedes consideraban sencillas pueden complicarse mucho más de lo que esperaban.

Esto es algo que yo no consideré al implementar este blueprint, así que lamentablemente no llegué al lanzamiento de G3 :( ¿Próxima meta? ¡H1!

Debugging

Una vez que finalicen la implementación y obtengan el resultado deseado deberán asegurarse de que su implementación no afecte a otros servicios.

Si mantuvieron el orden esta etapa debería ser relativamente rápida, y con suerte, requerir muy pocos cambios.

Esperar los reviews

Cuando estén listos deberán subir su trabajo a Gerrit, como lo hacen con cualquier bug, con git commit -a y luego git review.

Allí otros desarrolladores probarán la nueva implementación y podrán proveer sugerencias e ideas que mejoren aún más el trabajo realizado.

Merge

Finalizado este proceso, un core developer aprobará el cambio y habrán logrado su primera gran contribución al proyecto.

Más información

En este artículo incluí el flujo de trabajo normal para la creación e implementación de una funcionalidad en un proyecto. Podrán encontrar información más detallada sobre ciertos puntos que mencioné en las siguientes fuentes.

Comments (1)

Leave a Comment

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>