La nube aporta mejoras en el desarrollo de software

Durante los últimos meses la nube entra por todos lados, cada rincón de la empresa de software es susceptible de viajar a la nube.

Hay muchos ámbitos donde puede aportarnos soluciones mejores y más económicas.

Pruebas

Una de las áreas donde el Cloud esta ayudando es el área de pruebas, ya que permite arrancar una máquina limpia de manera rápida, ejecutar las pruebas y eliminarla.
Todo el trabajo de instalación de sistemas operativos desaparece. El coste de una hora de una máquina incluyendo licencias de sistema operativo  suele ser inferior al euro. Hacer eso en local lleva mucho más tiempo y dinero.

Esclavos en la nube

Si usas integración continua con Jenkins, es muy cómodo tener los esclavos en la nube. Estas máquinas son las encargadas de realizar la compilaciones, verificaciones,  pruebas funcionales, etc. En nuestro caso usamos múltiples esclavos para los diferentes sistemas operativos y sus diferentes sabores.

El ahorro más importante viene en que podemos arrancar las máquinas esclavas a demanda, ahorrándonos el coste de tenerlas siempre encendidas. También es muy sencillo cambiar los recursos de las maquinas en función de las necesidades.

Más madera

Otro de los puntos fuertes son las pruebas de carga, estos proveedores te permiten contratar monstruos de la computación. Se pueden montar pruebas de carga con varios equipos de 64 núcleos con cientos de Gigas de RAM. Es posible probar el rendimiento en grandes infraestructuras por unos pocos euros.

Seguridad

En cuanto a la seguridad de las máquinas, es eficaz mantener una política dura en la configuración del firewall del proveedor de Cloud, con lo que no tendremos problema en la configuración o reconfiguración individual de cada máquina virtual.

Como alternativas tenemos experiencia en Amazon Ec2 y Arsys Cloud builder, pero existen decenas de proveedores que pueden ofrecer un buen API para la gestión de las máquinas.

¿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