En el desarrollo de software moderno, sobre todo al lanzar nuevas versiones, muchas veces se necesita desplegar la misma aplicación con configuraciones distintas. Según dónde se despliegue el software y otros factores o requisitos del entorno, estas configuraciones pueden modificar el comportamiento de la aplicación. Algunos ejemplos de las variables mencionadas: múltiples ubicaciones geográficas, nuevos locales, distintos casos de uso, etc.
La elección del desarrollador
**Configuraciones de software: explicadas**
Cuando hablo de configuraciones distintas, es clave entender que la mayor parte del software es idéntica. Solo difieren algunas partes relativamente pequeñas. Por ejemplo, supongamos que tienes una cadena minorista y necesitas desplegar software para las cajas registradoras. La mayoría de los despliegues serán iguales. No haría falta un software completamente diferente para cada caja según la ubicación de la tienda. Aunque en algunas situaciones podría ser así.
Volvamos a la configuración. Sigamos con el ejemplo de la aplicación de cajas registradoras. Cada estación que ejecute la aplicación debe tener un identificador único: a eso le llamamos configuración. Distintos países pueden requerir distintos idiomas predeterminados: configuración otra vez. También están los desarrolladores, que necesitan su propio "entorno de dev": de nuevo, configuraciones que varían ligeramente. Pero el software es el mismo en todos los casos. Ya te haces una idea.
Hoy ya almacenamos todos los cambios del código fuente en un control de versiones. En algunos casos, contamos con un proceso que compila el código fuente en distintos tipos de binarios, archivos comprimidos o contenedores Docker. La razón es simple: distribuir la "versión" correcta del software de forma más eficiente.
Separar para potenciar y optimizar
El artefacto de software distribuido tiene que encajar con la configuración del entorno donde va a ejecutarse; por lo general, distintas piezas de configuración que pueden aplicar a distintos niveles, con cierta jerarquía de por medio. Esta configuración puede llegar a la aplicación por diferentes vías: variables de entorno, carga de archivos predeterminados con datos de configuración, respuestas de llamadas a APIs hardcodeadas o "configuradas" (mediante otro método), entre otras.
La idea principal es que esta configuración es dinámica y cambia con el tiempo. Puedes empaquetar TODA la configuración y desplegarla EN TODAS PARTES cada vez junto con la aplicación. Pero esa es una práctica poco eficiente que se puede (y se debe) optimizar. Esto se logra con una cadencia distinta para el despliegue y la liberación de los datos de configuración, separada de la aplicación en sí.
Y esa es la idea central de la optimización: separar el control de versiones y la gestión de los datos de configuración del código de la aplicación. Esta separación funciona mejor cuando la configuración tiene su propio espacio de versionado, con un proceso de despliegue propio para liberar los cambios. Es un proceso desacoplado del que se usa para los despliegues de la aplicación y, además, con su propia cadencia.
¿Qué opinas?
¡Gracias por leer! Para seguir en contacto, síguenos en el DoiT Engineering Blog , el canal de DoiT en LinkedIn y el canal de DoiT en Twitter . Para explorar oportunidades profesionales, visita https://careers.doit-intl.com .