Dedica tiempo a construir un proceso para la Release

En mi paso como Release Manager aprendí, qué si queremos hablar de calidad del software, se necesita tener un buen control de versiones, así como llevar una buena gestión de las Releases. Son dos piezas fundamentales para crear una base para definir la entrega del software.

Por otro lado, si queremos ir hacia la integración continua, e integrar código de manera rápida y frecuente, necesitamos gestionar bien todo el proceso de la Release. Analizar qué control de versiones vamos a utilizar, la manera de cómo trabajaremos las ramas, en que entornos haremos las pruebas, que código vamos a subir y cuales son todas sus dependencias.

CONTROL DE VERSIONES

Nos permite recuperarnos fácilmente de los errores, revisar los cambios pasados, colaborar con otros desarrolladores, hacer copias de seguridad del código y automatizar las tareas relacionadas con el código.

Hay muchas plataformas de control de código en el mercado: GIT, SVN…

Recomiendo analizar bien la estructura de ramas que queremos gestionar por proyecto, con el fin de poder trabajar con diferentes proyectos en paralelo, tener una rama de urgencias para hacer subidas rápidas y para que no se pierda código entre las diferentes subidas.

RELEASE MANAGEMENT

A lo largo del proceso del desarrollo de software, el código pasará por ciclos de desarrollo, pruebas y fixes. Con en el fin de probar y entregar el software de manera efectiva, es imprescindible tener un proceso de despliegue sencillo y fiable.

Es muy importante:

  • Definir los procedimientos de subida a producción y trabajar con la creación de tags y Release candidata.
  • Calendarizar las subidas a los entornos de Staging y producción
  • No nos olvidemos de la Release Notes, para documentar todo lo que abarca esta subida a nivel de funcionalidad y de solución de incidencias.
  • Pensar en una nomenclatura sencilla.
  • Ligar la información de la Release a una herramienta de gestión de proyectos, como podría ser JIRA.
  • Con un buen proceso de entrega, podemos estar confiados en las actualizaciones sin miedo a molestar a nuestros clientes. Una de las ventajas más grandes de la buena Gestión de la Release es la capacidad de marcha atrás en caso de una emergencia.

ENTORNOS

Necesitaremos, al menos dos entornos: el de desarrollo y el de producción. Y si queremos añadirle calidad al proyecto, necesitamos también:

  • El de Staging, dónde se harán las pruebas de calidad.
  • Para que dirección valide que el código cumple con los requisitos definidos, usaremos el de UAT.

El control y la coordinación de la versión en cada entorno es importante para realizar pruebas y reproducciones fiables de los problemas.

BUILD 

Una compilación (Build) contiene principalmente el paquete compilado que podría incluir ejecutables, las bibliotecas, dependencias. El Equipo de desarrollo crea la compilación y la proporciona al equipo de despliegue para su instalación.

SCRIPT BASE DE DATOS

En el proceso de las subidas, un tema delicado es la de revertir el código en caso de que tengamos que volver a la versión original.

No se puede simplemente volver a la estructura anterior, se necesita crear una secuencia de comandos para dejar la Base de datos tal y como estaba antes de la subida. No solamente de estructura, como podría ser el haber añadido una nueva columna, sino que también importan los datos.

De primera opción, en cada subida deberíamos tener un script de Upgrade, con todos los cambios que se registran en la Release a nivel de Base de datos, tanto de estructura como de datos. Así como también deberíamos tener preparado el de downgrade, que lo que haga es revertir todo lo que ha hecho el script de subida y dejar la Base de datos, tal y como estaba, tanto a nivel de estructura como en datos.

En caso que se hayan hecho muchos cambios en la BDs y la programación de estos scripts comporten mucho tiempo de desarrollo, entonces se recomienda hacer una copia de la BDs justo antes de la subida, para tener una copia justo de antes.

DESPLIEGUE

Una vez el equipo entrega el Build, es muy importante validar que se despliegue correctamente en el entorno de pruebas, así nos aseguramos que la subida en producción haya errores. Pera ello debemos seguir bien los pasos descritos en la Release notes.