¿Cuantas hijas/versiones debo mantener?

En software es fácil tener muchas versiones de un mismo producto, las peticiones del cliente y el reducido coste de actualizar nos hace que podamos tener fácilmente varias versiones en producción de un mismo producto.

Crear, mantener y gestionar estas versiones puede ser tan laborioso como tener descendencia.

Una versión funcionando en un cliente es como una hija:

  • Has tenido que parirla y eso cuesta
  • Has tenido que darle un buen trabajo (Instalándola en los clientes)
  • Si tiene algún problema te llamará y tu eres el responsable de ayudarla
  • A una hija/versión no puedes abandonarla
  • Cuantas más hijas/versiones distintas tengas en producción más difícil será “mantenerlas todas”
  • Cuantas más versiones, más te costara “identificarlas”. Ponles nombres
  • En reyes (cambio legal en la aplicación), tendrás que hacerle un regalo a todas 😉
  • Cuantas más hijas/versiones, más posibilidades que te salga alguna rebelde

Ten pocas y buenas hijas/versiones, te darán menos guerra y entrareis todos en casa en Nochebuena.

¿Cuál es tu ciclo de desarrollo? (release cycle)

Escaleras que nos ayudan a subirLa salida de una versión de un producto de software suele ser el punto final de un gran trabajo, pero el principio para muchos otros. Por este motivo, es importante tener claro y transmitir al equipo interno y los usuarios como es nuestro ciclo de desarrollo. De esta manera nadie tendrá falsas expectativas respecto al qué y el cuándo.

Nuestro ciclo de desarrollo debe aclarar al menos :

  1. Duración del ciclo de desarrollo completo.
  2. Numeración de las versiones a publicar.
  3. Tipos de versiones que aparecerán en cada ciclo (Beta, RC, Final, Parche, etc.)
  4. Condiciones que se darán para la salida de cada tipo de versión.
  5. Entregables que tendremos en cada tipo de versión.
  6. Definir cuando esa versión no tendrá más mantenimiento o soporte.

1. Duración del ciclo de desarrollo

Totalmente relacionado con las iteraciones que hagas en tu compañía. El tiempo depende de cada producto o empresa, pero es importante tenerlo definido y no cambiarlo para no confundir a ninguno de tus stakeholders

2. Numeración de las versiones

Durante la vida de una aplicación existirán muchas versiones y es importante que todos sepamos identificarlas para conocer que cambios tiene respecto al resto de versiones.

3. Que aparecerá en cada ciclo

En cada ciclo de desarrollo, generalmente, aparecerán distintos tipos de versiones:

  • Una versión beta para probar las novedades y poder distribuir entre usuarios más expertos.
  • Una versión release candidate con la supuesta versión final (Antes de los últimos detalles)
  • Una versión final que se distribuirá entre todos los usuarios.
  • Unos posibles parches que arreglarán problemas una vez publicada la versión final.

No todos los productos funcionan igual ni necesitan todos estos tipos de versión.

4. Condiciones que se darán para la salida de cada tipo de versión

Esto hace referencia especialmente a los “parches”, debemos definir cuando y como saldrán los parches. No todos los cambios de nuestro software tienen porque generar un parche, en general solo los errores graves o que rompen una funcionalidad anterior deben convertirse en un parche. Publicar un parche tiene un coste operativo alto, en muchos casos con incluir ese cambio en el siguiente ciclo de desarrollo es suficiente.

5. Entregables que tendremos en cada tipo de versión

Cada tipo de versión es un mundo, en algún caso el entregable es un .zip o una url (beta), en otro son una url, instalable, pdf, documentación, vídeo, post, traducciones, etc.
Hacer un checklist de lo que incluye cada tipo de versión ayuda a preparar todo lo que liberaremos en cada parte del ciclo de desarrollo.

6. Definir cuando una versión no tendrá más mantenimiento o soporte.

Todas las versiones tienen un tiempo de vida, no podemos permitirnos dar soporte y mantenimiento a todas las versiones que han aparecido durante toda vida de una forma indefinida. Este tiempo pueden ser años y todos los stakeholders deben conocer este tiempo para saber cuando tienen para actualizarse a nuevas versiones.

Enlaces a información de ciclos de desarrollo de distintas aplicaciones :

Release Cycle de Confluence
Mcafee release cycle
Ciclo de desarrollo de Velneo
Blender Relase Cycle
Release Cycle de Fedora

Números de versión de tu software

Nombre para las versionesTodas las divisiones hacemos software y más quien menos trabaja todo el día con versiones de aplicaciones. La versión de desarrollo, la versión del cliente Pepiño, el parche que arregla el problema, la versión de ayer, la nueva y revolucionaria versión.

Todas las versiones deberían llevar un nombre, un nombre que nos permita :

  •  Identificar inequívocamente un estado de nuestra aplicación en un momento dado (Firmar)
  • Conocer con quien “se lleva” bien esta versión (Integración)
  • Permitir conocer en que ciclo/iteración se ha desarrollado
  • Marca comercial principal (año, funcionalidades principales)

Existen muchos tipos de numeración de versiones :

http://en.wikipedia.org/wiki/Versioning

En el Grupo estamos unificando el criterio a la siguiente configuración:

Esta compuesto con cuatro dígitos que nos permite tener la suficiente flexibilidad para cubrir todas las necesidades de las distintas configuraciones.
11.3.0.9323

  • 11.xx.xx.xx – Versión mayor (Cambio mayor de la aplicación con cambios importantes. Esta numeración suele estar marcada por cambios estratégicos comerciales en la división que pueden ir acompañados por una buena campaña de comunicación )
  • xx.3.xx.xx – Versión menor ( Es el ciclo básico de trabajo y son los cambios programados para ese ciclo de desarrollo, se supone que va acompañado con pruebas, novedades y documentación, videos, etc )
  • xx.xx.0.xx – Parche ( Son los inevitables parches que arreglan un problema y deben poder publicarse rápidamente, no se acompañan de novedades ni de documentación ya que estas versiones deben poder sacarse rápidamente, lo ideal es no sacar ninguna)
  • xx.xx.xx.9323 – Sello ( Es lo que identifica inequivocamente a la versión, evita que existan en la calle dos aplicaciones distintas con el mismo número de versión. Muy cómodo cuando en soporte o programación usan decenas de versiones en el día a día. Es un número consecutivo que puede ser el Build/Changelist/etc

FAQ
A mi me gusta lo de Snow Leopard, Lion, froyo, gingerbread. ¿Por qué no usamos nombres frikis?
Todo nombre friki tiene un número de versión “técnico”, lo de los nombres comerciales es para “nenazas” y aquí somos muy “pros”.

Menudo rollo, por la fecha del fichero se puede saber, y es más cómodo que aprender todo esto.
En algunos casos la fecha puede servir, pero al mover los ficheros de sistemas esa fecha puede cambiar y la sorpresa a la hora de poner en un cliente puede ser monumental.

¿Qué numero le pongo a una beta que no quiero que se ponga en un cliente?
Si tienes una versión interna de pruebas y no quieres que se le ponga a un cliente, tenemos que decidir poner algo en el número de parche que identifique esa circunstancia por ejemplo 11.3.99999.9423. 11.3.BETA.9432