En el Manifiesto Agil el primer principio dice así:

«Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software útil»

Uno de los enfoques más importantes es poder dar al cliente software funcionando para que lo pruebe y nos aporte el feedback que permite hacer la aplicación cada vez más valioso para el cliente. Además, en la parte técnica, hacer entregas más frecuentes reduce el riesgo de cada una de ellas.

En el desarrollo tradicional. Las tareas de desarrollo y test se van acortando según se acerca el deadline. Durante todo el tiempo no se puede hacer release porque siempre hay desarrollos sin completar por uno u otro desarrollador. Cuando todo el testing ha terminado y todos los bugs y desarrollos se han cerrado es el momento de hacer el release de la aplicación.

Usando Scrum esto mejora algo:

Reduciendo el tiempo de entrega y haciendolo más frecuente podemos ajustarnos más a los deadlines pactados con los clientes. Durante el sprint el código se considera no releaseable ya que solamente cuando se termina éste, todos los desarrollos se han cerrados y estan libres de bugs conocidos.

Aunque Scrum es un gran avance respecto al desarrollo tradicional, se puede ir más alla y poder ofrecer actualizaciones de manera continua y temprana. Hay varias formas de conseguir esto:

Forma 1: Desarrollar historia por historia

Todos los desarrolladores trabajan en la misma historia y se hace release cuando se termina. Esta es la manera más dura de conseguirlo. Hace falta gran madurez en el equipo pero también reduce el tiempo de desarrollo de cada historia. Durante el tiempo de desarrollo el código se considera sucio ( no releaseable) pero estos intervalos son cortos.

Pero claro, quizá tu eres uno de los que dice. No todo se puede paralelizar, 9 embarazadas no dan a luz un niño cada mes.

Sin embargo, en cuestión de desarrollo se puede paralelizar mucho las historias. Hay back-office y fron-end. Hay clases de store, de vista, de controlador, hay que desarrollar los tests, hay que preparar los scripts de bases de datos. Todos estos son tareas que algunas se pueden realizar en paralelo por varios desarrolladores. Necesita organización y planificación previa del equipo y coordinación durante el desarrollo. Así es como lo veo yo:

Forma 2: Feature branching.

El auge de los nuevos sistemas distribuidos de control de código (DVCS) como Git, Mercurial o Plastic SCM tambien tienen características que permiten hacer branches a menudo. Esto es usado para hacer un branch por historia a desarrollar o feature branching. Una vez completada esa historia se incorpora a las ramas principales que sea necesaria para hacer el deploy.

Esto es un ejemplo de branches usando un sistema de feature branches y varias ramas de integración. Hay partidarios de los features branches pero yo me inclino más por la opinión de estos dos conocidos personajes.

Martin Fowler y Jezz Humble afirman que el uso de feature branches va en contra de la Integración Continua, necesaria para tener feedback de integración temprano y realizar los merges con las ramas principales menos dolorosos. Además es necesario una gran bateria de tests automaticos para evitar bugs ya que es necesario testear la funcionalidad varias veces. Primero en la rama en la que se desarrolló, después en cada una de las ramas en la que se integra. Si es necesario el tests manual esto puede ser muy doloroso. Sólo recomiendan el Feature Branching en equipos muy muy maduros.

Forma 3: Feature Toggle.

Esto se basa en poder desarrollar las funcionalidades, teniendolas integradas junto con el resto del código pero que no afecte al producto si se tiene que hacer release a mitad de desarrollo. El truco está en desactivar el link o el acceso a la nueva funcionalidad hasta que esté completamente desarrollado y testeado.

Esta tercera forma, aparte de permitir hacer release a cada momento teniendo el código integrado también tiene una serie de ventajas extra.

Ventaja 1. Canary Releasing.

Este concepto proviene del sistema utilizado en las minas para detectar fugas de gases. Ponían jaulas con canarios a lo largo de los tuneles y estos, al ser más delicados que las personas, morían rapidamente en caso de fuga de gas letal. Efectivamente es una tecnica un poco triste por perjudicar a los canarios pero hay que contrastarlo con las vidas humanas que salvavan.

Moviendonos al terreno del software (donde hay menos gases involucrados), el Canary releasing significa poder ir activando funcionalidades por zonas. Primero las activaríamos en sistemas internos, después en sistemas de clientes con confianza y si todo funciona correcto al final se activaría en clientes críticos. Si en alguna de estas zonas da problemas, dejaríamos de avanzar antes de resolver el problema

Ventaja extra 2. Marcha atrás rápida.

Alguna vez habeis programado una actualización a un cliente, se le ha dicho que con esta nueva versión va a tener los bugs encontrados arreglados y además la nueva funcionalidad. Ejecutas el instalador, actualizas el sistema y la nueva funcionalidad no va ni para atrás y los usuarios se empiezan a quejar. La opción normal es 1.- Gritar, 2.- Desinstalar la última versión instalada,3,. Deshacer manualmente los cambios que hubiera hecho el instalador que no hace al desinstalar,.4.- Instalar la versión anterior. 5,. Volver a gritar.

Mediante el Feature Toggle nos permitiría poder simplemente desactivar la nueva funcionalidad sin tener que desinstalar. En cuanto la tuvieramos arreglada y el sistema actualizado, solamente se vuelve a activar. Bastante menos doloroso.

Ventaja extra 3: Customización del producto.

A todos nos ha llegado las estadisticas de que los usuarios sólo utilizan una pequeña parte de la funcionalidad. Con el resto ocurre dos cosas: 1. Les molesta que esté o 2,. Nos molesta que lo toquen. La opción más sencilla es desactivar la funcionalidad que no van a necesitar haciendole el interfaz más sencillo y evitando posibles problemas.

Implementación propuesta.

En VSN vamos a tener una tabla por producto. En esta tabla habrá una entrada por característica candidata a ser activable o desactivable por el feature toggle.

En entorno de desarrollo y test se le pondrá a todas las filas la columna ACTIVE a true así aparecerá todo para probar. Sin embargo, en el SQL de release sólo estarán activas las funcionalidades completadas y que formen parte del producto por defecto. De este modo aprovechamos todas las ventajas de este sistema. Le hemos añadido una columna leible por humanos porque todo esto seguramente acabe en un panel de activación y desactivación para un futuro «Gate Keeper» guardian de las características.

Actualización 7/6/2012: Nosotros instalamos de momento sólo sistemas llave en mano. Es decir, instalamos en cada cliente una máquina con el server. En cada server hay una base de datos y en esa base de datos se puede activar o desactivar sus features. Así sí que se permite activar y desactivar por Canary Release. Si el sistema está en la nube falta añadir a la tabla una columna referente a el area del cliente (definida por tí) , region geografica y sacar su region por geoip,.. o algún otro tipo de agrupar los clientes.