Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: revisión de código

Sobre código, revisiones y despliegues

Lo sé. Lo admito. Me encanta la sensación de acabar de programar algo a las 5 de la mañana. Satisfecho. Orgulloso. Tal vez con un exceso de cafeína. Mergeas, despliegas y a dormir con una sonrisa. En tus sueños un cowboy se monta en su caballo, llega al pueblo y desmonta bajo la mirada de los pueblerinos. Captura a los malos, se sacude el polvo y se va triunfal con los suspiros de aquellos y aquellas a sus espaldas. Sí, ese desarrollador cowboy que es capaz de hacerlo todo, sin hablar con nadie, sin consensuar nada.

Te levantas con la sonrisa todavía en la boca (dejemos de lado babas y otros sucesos paranormales). Vas al ordenador y ¡boom!, algo ha ido mal. La explosión despierta hasta al cowboy de tus sueños, que se tapa con una piel y se acurruca junto a la hoguera, ahora hay miedo en ojos del valiente cowboy. Creo que esta historia nos suena a muchos y a muchas. Y sí, los sueños y las sonrisas, e incluso las risas molan; pero mejor dejar las explosiones para nuestros proyectos locos y no para los serios, o para el trabajo.

Historias de usuario públicas. Ramas. Revisión de código. Pruebas manuales. Pruebas automáticas. Despliegues. El cowboy puede hacer lo que quiera, que vamos a hacer que esto no explote (o mejor dicho, que explote cuanto menos, mejor).
Seguir leyendo

Segundo Coding Dojo de Frogtek en Walqa

Tras el éxito del Primer Coding Dojo y la resaca de la visita de Richard Stallman ya va siendo hora de presentar el Segundo Coding Dojo de Frogtek en Walqa.

Rubén Bernárdez de Biko2 será nuestro maestro de ceremonias. Aquellos que estuvisteis en el primer dojo recordaréis a Rubén ya que fue uno de los dos valientes (el otro era Dani Latorre) que retados por Carlos Ble se marcaron un refactor de la kata de Carlos, improvisado, sin red y ante la admiración de todos los asistentes.

Así que no hacen falta más presentaciones, ahora ya todos sabemos lo que es un Coding Dojo y por lo tanto, sin más, os dejamos con los detalles de nuestra próxima cita. Os esperamos.

  • Día: viernes, 8 de abril de 2011
  • Lugar: Parque Tecnológico Walqa, Edificio de Servicios Generales
  • Horario: de 16:00 a 21:00 aproximadamente
  • Precio: Totalmente gratuito
  • Quién puede apuntarse: cualquier persona, independientemente de que trabaje o no en Walqa
  • Agenda:
    • Rubén propondrá uno o varios problemas sobre los que se trabajará en parejas.
    • Se realizarán varias iteraciones.
    • Al final de la sesión Rubén presentará y explicará su solución a todos los asistentes.
  • Plazas: Limitado a 35 personas, por riguroso orden de inscripción
  • Inscripción: Mandando un mail a Walqa (walqa@ptwalqa.com)

¡¡Animaos que seguro que lo pasamos muy bien!!.

Frogtek organiza un Coding Dojo en Walqa con Carlos Ble de invitado

El próximo viernes 21 por la tarde en Walqa, Frogtek organiza un Coding Dojo de la mano del experto en Test-Driven DevelopmentMetodologías Ágiles y Cloud Computing, Carlos Ble.

Un Coding Dojo es un evento informal y divertido en el que un grupo de programadores se reúne para poner en práctica sus habilidades de programación, resolviendo pequeños problemas programando por parejas en diferentes lenguajes. Es una oportunidad muy buena para aprender nuevas técnicas, nuevos lenguajes, conocer gente interesada en el mundo de la programación y obtener consejo de un experto como Carlos.

  • Día: 21 de enero de 2011
  • Lugar: Parque Tecnológico Walqa, Edificio de Servicios Generales
  • Horario: de 16:00 a 21:00 aproximadamente
  • Precio: Totalmente gratuito
  • Quién puede apuntarse: cualquier persona, independientemente de que trabaje o no en Walqa
  • Agenda:
    • Carlos propondrá uno o varios problemas sobre los que se trabajará en parejas.
    • Se realizarán varias iteraciones.
    • Al final de la sesión Carlos presentará y explicará su solución a todos los asistentes.
  • Plazas: Limitado a 25 personas, por riguroso orden de inscripción
  • Inscripción: Mandando un mail a Beatriz Lorente (blorente@ptwalqa.com)

¡¡Animaos que seguro que lo pasamos muy bien!!.

Frogtek Kanban Boards

En Frogtek tenemos dos tablas de kanban distintas en paralelo, una para los Product Owners y otra para el equipo de Tecnología. Primero nació la de Tecnología, como una manera fácil y visual de controlar el trabajo, lo que queda pendiente, lo que está ya acabado o lo que está siendo programado en este momento. El proceso de desarrollo es lo suficientemente “complicado” (tampoco mucho) como para que sean necesarias varias columnas, pero ¿por qué necesitamos también una tabla de kanban para el proceso de diseño de una user story por parte de los Product Owners?. Principalmente, y esto es lo único que voy a contar al respecto antes de centrarme en la tabla de Tecnología, porque el proceso de definición de user stories se ha ido complicando conforme añadíamos técnicas como el Usability Testing y demás y ahora requiere de varias iteraciones antes de que una user story quede archivada y por lo tanto disponible para ir al Backlog de Tecnología, es decir, a la fase de producción.

La tabla virtual de los Product Owners.

Moraleja: las tablas de Kanban son muy útiles incluso si lo que quieres organizar son las tareas del hogar, no es algo reservado a programadores o ingenieros.

La tabla virtual de tecnología.

Nuestra tabla real de tecnología (ver foto abajo) tiene una fila por proyecto y 6 columnas de las cuales forman parte del proceso estrictamente 4, las dos de los extremos no son más que los recipientes de donde salen las user stories y en donde acaban al final.

La tabla real de Tecnología

Son las siguientes:

  1. Backlog: aquí el Product Owner almacena las user stories que ya han pasado por todo el proceso de diseño (en la otra tabla) y están listas para ser empezadas cuando lo considere necesario, es una especie de almacén (los programadores no miran mucho dentro). También almacenamos bugs que cualquiera detecta y que no son muy urgentes, de esta forma el Product Owner puede evaluarlos, descartarlos o priorizarlos según su criterio.
  2. Development – User Interface: de alimentar esta columna se encargan tanto el Product Owner como la diseñadora gráfica. La idea es la siguiente, cuando una user story del backlog está lista (es decir, tiene una descripción exhaustiva y una lista de tests de aceptación) si requiere antes de su programación de la creación de recursos gráficos (iconos, imágenes…) entonces es la diseñadora gráfica la que la arrastra a esta columna (a la parte izquierda) y no la coloca en la derecha (que indica que la user story está lista para pasar a la siguiente fase) hasta que no ha creado todos los recursos y los ha adjuntado para que los usen los programadores. Si la user story, por el contrario, no necesita nada gráfico el Product Owner la mueve directamente a la parte derecha de la columna en espera de que un desarrollador la escoja. Sea como fuere, en este punto todas las user stories tendrán una descripción detallada, una lista de test de aceptación y si lo requiere ciertos archivos adjuntos con los recursos gráficos necesarios. En esta columna también aparecen de vez en cuando bugs urgentes (aquellos que alguien detecta y que hay que resolver enseguida).
  3. Development – Code: Esta columna es responsabilidad de los programadores, cuando uno de ellos se libera acude a la columna Development – User Interface y toma la user story que esté más arriba de entre las de la parte de la derecha. La user story (el post-it en realidad) se mueve a la parte izquierda de esta tercera columna y quedará allí hasta que el programador considere que ha terminado su trabajo. ¿Y eso que quiere decir?. Pues hasta que ha probado, en un entorno lo más real posible, que lo que ha programado cumple todos y cada uno de los test de aceptación diseñados por el Product Owner (amén de los tests unitarios propios y ajenos entre otras cosas). Entonces hace “commit” (o comitea en castellano antiguo) y cruza los dedos para que todo funcione y no haya “momento cerdito” (en ese momento la build se compila en el servidor y los test unitarios se ejecutan, así como los funcionales y los aleatorios… así que es como para echarse a temblar, lo del cerdito lo explicaremos en otro post dentro de poco). Si todo va bien es momento de mover la user story a la parte derecha de la columna donde esperará a que otro desarrollador inicie el proceso de revisión. Por cierto, IMPORTANTE,  esta columna es la única a la que aplicamos WIP (limitación del Work In Progress) y normalmente lo limitamos al número de programadores en el proyecto menos uno. De esta forma no podemos tener dentro de la columna más user stories que programadores en el proyecto menos uno. Lo que hace que, a veces, cuando alguien acaba su tarea se vea obligado a revisar alguna de las user stories que otros hayan acabado para vaciar la columna o a hacer pair programming.
  4. Quality – Review: el proceso de revisión es doble, primero por parte de un desarrollador, que no haya participado en la programación de la user story, y luego por parte de nuestro responsable de QA, Julio. Consiste en utilizando la herramienta Review Board revisar que todo el código y ver que el código es consistente en estilo y con un diseño eficiente. Si hay algún tipo de comentario, el programador original deberá modificar el código y volver a pasar pruebas manuales y automáticas. Al final del proceso y si todo va bien la user story acaba en la parte derecha de la columna esperando a que el responsable de calidad la testee.
  5. Quality – Test: ya estamos llegando al final del proceso. Aquí es donde las cosas se ponen más interesantes ya que Julio se dedica a comprobar que todos y cada uno de los test de aceptación definidos por los Product Owners se han satisfecho. Si encuentra algún error, la user story vuelve directamente a la columna 3 (Development – Code) y el momento cerdito es acogido con regocijo por toda la oficina (menos aquel a quien se le aplica). Esto es un poco como esas casillas del juego de la oca que te mandaban 20 casillas atrás… hay que volver a empezar y arreglar lo que no funciona. Cuando los tests se pasan correctamente la user story se deja en la parte derecha de la columna esperando a que el Product Owner que es quien debe dar al final el visto bueno la archive definitivamente.
  6. Archive: cuando una user story está en la parte derecha de la columna Quality Test es señal de que el trabajo está listo para que el Product Owner lo pruebe. Si comprueba que todos los tests de aceptación se pasan directamente puede mover la tarea a esta sexta columna donde quedará para siempre. Si hay algún error entonces la tarea vuelve a la tercera columna, todo vuelve a comenzar y el “momento cerdito” planea sobre nuestro querido Tester.

Algunos comentarios:

No diferenciamos entre user stories y bugs, salvo por el color del post-its, eso es importante. Los tratamos igual. Un bug normalmente no tendrá test de aceptación, archivos gráficos adjuntos pero si una descripción detallada. Cuando los errores se identifican durante la fase de testeo, no se genera un bug, sino que se rechaza la user story. Si se detectan después, sí y, en ese caso, su destino será: el backlog si no son urgentes, la parte derecha de la columna de Dev – User Interface si lo son o la parte izquierda de la columna de Dev – Code si son críticos. El triaje lo realiza normalmente o el responsable de QA, el Kanban Master o el Product Owner si está disponible (nótese la diferencia horaria, 6-7 horas, entre POs y programadores).

¿Cómo es posible que el tester pueda testear “instantáneamente” cada una de las user stories tras el commit?. Gracias al sistema de integración continua del que ya hemos hablado en varios posts. Cada commit genera una nueva versión de pre-producción que nos sirve para testear lo último que se ha terminado. No hay más que seleccionar buscar actualizaciones en nuestra aplicación y el “upgrade” es automático.

En los pantallazos correspondientes a nuestra tabla virtual (que en el fondo es la oficial, porque es la única que compartimos toda la empresa) no hay lado derecho o izquierdo de las columnas. Simplemente cuando una user story está lista le ponemos un reborde verde.

Si os fijáis en las imágenes que hemos adjuntado la tabla real no tiene columna “Archive” esto es así porque realmente hemos encontrado una utilidad mucho mejor para las user stories (los post-its) terminadas que coger polvo o ir a la caja de reciclar. Lo contaremos en nuestro próximo capítulo junto con lo del “momento cerdito”.

Servidor de desarrollo

Servidor de desarrollo

Os presento a nuestro servidor de desarrollo: DarwinFrog.

Debido a nuestra pasión por la integración continua, las revisiones de código, las herramientas de calidad y los tests automáticos; el pobre servidor está pluriempleado.

A modo de recuento las herramientas que habitan nuestro servidor y nos ayudan en nuestras tareas diarias son:

  • Hudson servidor de integración continua, lleno de plugins para adaptarse al desarrollo en Android y Gae.
  • Subversion en estos momentos nuestro sistema de control de versiones, estamos pensando migrar a algo más moderno como Git o Mercurial, pero no encontramos el momento adecuado.
  • Sonar plataforma de control de calidad del código, muy completa y visual.
  • Review Board herramienta de revisión de código muy útil y fácilmente enlazable con Subversion y otros sistemas de control de versiones.
  • Nexus gestor de repositorios muy útil para almacenar artefactos propios generados por Maven y así no tener que preocuparse de las versiones de las librerías, ni de las dependencias.
  • Seleniumhq plataforma para realizar tests funcionales web, versátil y fácilmente integrable con Hudson. Permite grabar los test de forma muy sencilla desde firefox entre otros.

En próximos posts intentaremos entrar en más detalle y contaros más a fondo como utilizamos y para que cada una de las herramientas.