Autor: M. en C. Alejandro Cruz Rojas Sígueme en LinkedIn
Introducción
Este artículo es la cuarta parte del artículo previo “Diseño de Software as a Service: Los 12 factores” Puede acceder al documento descrito en alguno de los siguientes enlaces:
- https://es.linkedin.com/pulse/dise%C3%B1o-de-software-service-los-12-factores-alejandro-cruz-rojas-j71gc
- https://www.qualitrain.com.mx/diseno-de-software-as-a-service-los-12-factores/
¿Cuál es el problema?
Vamos a suponer que tenemos un equipo de desarrollo que implementa una aplicación. A esa aplicación se le van agregando paulatinamente nuevas funcionalidades, ya sea derivadas de nuevos requerimientos o bien, como resultado de las correcciones de defectos.
Ese mismo equipo de trabajo, cuando considera que ha probado suficientemente una nueva versión del software va y la instala en el ambiente productivo (desde ahí es usada por la comunidad de usuarios). ¿Qué podría salir mal?
Existe otro equipo de trabajo de “soporte a la producción” que es responsable de vigilar que el ambiente productivo esté en condiciones óptimas y de atender las incidencias que se presenten en el uso de la aplicación por parte de los usuarios. Este equipo no tiene dominio sobre la programación de la aplicación, pero la conoce a nivel funcional.
El modelo de trabajo descrito tiene que lidiar, continuamente con escenarios como los siguientes:
- Eventualmente, tras la instalación de una nueva versión, su ejecución inicia correctamente. Sin embargo, el software se va degradando paulatinamente debido a algún error de diseño no detectado. Los usuarios tienen un tiempo de respuesta cada vez más lento… hasta que la aplicación colapsa (en horas no hábiles).
- Por ventanas de mantenimiento, se apaga la aplicación en el equipo productivo por breves periodos de tiempo y se reinicia la computadora. El equipo de “soporte a la producción” arranca nuevamente la aplicación, pero esta falla repentinamente por razones desconocidas. (Quizás algunas variables de ambiente perdieron sus valores previos…).
- Se restaura un respaldo que cambia el ambiente productivo, la aplicación para repentinamente. Nadie entiende qué está sucediendo.
¿Qué propone el factor 5?
El factor 5 reza “build, reléase, run”
- ¿Qué significa? Separar los procesos de: a) construcción del empacado, b) deployment de ese empacado y c) ejecución de éste en el ambiente productivo.
- ¿Para qué? Para que las aplicaciones que se ejecutan en el ambiente productivo estén disponibles todo el tiempo (o casi). Se trata de que el equipo responsable pueda reiniciar limpia e independientemente la ejecución de una aplicación en producción. Así mismo, en caso de un error irrecuperable, pueda ejecutar la versión inmediata anterior.
La idea parte de las siguientes premisas:
- Las ejecuciones (en ambientes productivos) son susceptibles de fallar a cualquier hora, sin que haya alguien que pueda corregir la causa de inmediato.
- Las ejecuciones (en los ambientes productivos) pueden incluso reiniciarse automáticamente en casos como: un reinicio del servidor o bien, un proceso bloqueado que se reinicia por el administrador de procesos
¿Cómo separar construcción, deployment y ejecución?
Para conseguir la separación requerimos:
- Contar con repositorios especializados de distintos tipos de artefactos: código fuente, empacados distribuibles junto con sus configuraciones productivas (releases) y artefactos ejecutables (builds).
- Tener un proceso, llamado “construcción”, que tome el código fuente (ya probado exhaustivamente) y las librerías (internas y externas), y los transforme en empacados (releases).
- Tener otro proceso, llamado “deployment” o “distribución”, que una el empacado generado por el proceso de construcción, con la configuración apropiada para el ambiente productivo, en un artefacto ejecutable conocido como “build” (típicamente un archivo de comandos).
- Tener un proceso, llamado “ejecución” que automatiza la ejecución en el ambiente productivo, de los artefactos ejecutables generados por el proceso de “deployment”.
¿Cómo funciona el proceso de “construcción”?
Este proceso trabaja con las premisas siguientes:
- Se tiene código fuente que ya ha sido probado exhaustivamente; que corresponde con un grupo de adiciones y/o cambios; y que están relacionados con nuevas funcionalidades o bien con correcciones de defectos.
- El grupo de cambios y adiciones se tiene catalogado como una nueva versión distribuible.
- El código fuente mencionado, se ha colocado en un repositorio dedicado.
- Ese código hace referencia a librerías internas y externas que se guardan en un repositorio institucional.
El proceso de “construcción” debe, valga la redundancia, construir un empacado en algún formato distribuible. (Cada plataforma tiene archivos especializados de este tipo. Por ejemplo, en Java tenemos los formatos “.jar”, “.war”, etc., en la plataforma Net tenemos los “.dll”).
¿Cómo funciona el proceso de “deployment”?
En este proceso se llevan:
- el control de los releases,
- la gestión de configuraciones productivas
- la generación de los artefactos ejecutables para el ambiente productivo.
A cada empacado se le etiqueta como “Release” y se le asigna un ID de versión único, cómo:
- Una marca de tiempo de la versión (por ejemplo, 2011-04-06-20:32:17)
- Un número creciente (como v100)
- Un id de “versionamiento semántico” (cómo 2.3.45).
Ese ID no se puede modificar una vez que se crea. Cualquier cambio debe crear un nuevo release.
Este proceso se encarga de diseñar y mantener las configuraciones que cada release usará en el ambiente productivo. La configuración corresponderá en estructura con la que espera el empacado (un archivo de configuración específico, un script que da valor a variables del sistema, etc.).
La responsabilidad final de este proceso es generar un artefacto ejecutable, denominado “build”, que una el empacado con la configuración. Lo más simple es generar un archivo de comandos que es ejecutable desde un comando del sistema operativo. (Por ejemplo, un Shell de Linux o un script de PowerShell para Windows). El artefacto final (con sus archivos auxiliares) debe ser colocado en su repositorio correspondiente (un repositorio de “builds”).
¿Cómo funciona el proceso de “ejecución”?
La premisa de este proceso es que no hay tiempo suficiente para reaccionar ante la caída de una aplicación. Por esta razón, la etapa de ejecución debería ser ágil y lo más simple posible:
- manejar la menor cantidad posible de componentes ejecutables a administrar
- debería ser posible regresar a una versión anterior con rapidez para asegurar la continuidad en el servicio
El proceso de ejecución entonces debería auxiliarse de herramientas que automaticen la ejecución de los builds. Se trata de que se incorporen funciones de monitoreo que permitan:
- reiniciar un build que falle
- ejecutar un build de una versión anterior si se observa que un nuevo build es inestable.
Conclusiones
- La separación de los procesos de construcción, deployment y ejecución, persigue proteger las ejecuciones y mantener la disponibilidad.
- Se persigue la habilidad de reaccionar rápidamente a errores: Las herramientas de deployment suelen ofrecer funcionalidades de administración de releases que pueden regresar a una versión anterior (roll-back) rápidamente
- Se persigue proteger a la versión en producción de cambios imprudentes o accidentales en el código de la aplicación.
Por ahora, hemos comentado ampliamente el factor 5. Continuaremos con los otros factores en entregas futuras… No te las pierdas 🙂.