variables de entorno o archivos de configuración YAML

Question

El fondo:
Paso 1 -> Tenemos una caja que se ejecuta pruebas unitarias y funcionales de una aplicación mediante la ejecución en modo de prueba con una configuración específica.
Paso 2 -> Tras el éxito del Paso 1, ejecutamos pruebas de integración de una aplicación ejecutándola en modo de prueba con un conjunto de configuración diferente, en otro cuadro.
Paso 3 -> Tras el éxito del paso 2, ejecutamos las pruebas de rendimiento de una aplicación ejecutándola en modo de producción, en el cuadro de prueba de rendimiento.
Paso 4 -> Tras el éxito del paso 3, la construcción se considera estable y la caja UAT se actualiza con esa base de código y la aplicación se ejecuta en modo de producción, para la revisión y comentarios del cliente. Paso 5 -> Con GO del cliente, la caja de producción se actualiza con la base de código.

Ahora, en los pasos anteriores observamos que en los pasos 1 y 2, mientras la aplicación se ejecuta en modo de prueba, tiene una configuración diferente. Similar es el caso con los pasos 3,4 y 5.

En tales situaciones, ¿cuál es la práctica recomendada? Estábamos teniendo archivos de configuración de YAML, pero personalmente sentí que mantener numerosos archivos de configuración no tiene sentido. Y así, he cambiado de la práctica de
"El archivo de configuración por medio ambiente"
a
"El archivo de configuración por el modo de raíles, la externalización de las variables de entorno Linux a".

¿Estoy en el camino correcto? ¿Mi acción no simplifica las cosas?

¿Cuáles son los pros y los contras de estos dos enfoques?

Answer 1

En mi experiencia, las variables de entorno son la opción de configuración de último recurso.Definitivamente tienen su lugar, pero las aplicaciones generalmente deben verificar alguna otra opción de configuración más confiable y explícitamente intencional primero. Recomiendo cargar la configuración de un archivo YAML y solo usar una variable de entorno como alternativa. Siempre suponga que su variable de entorno se aplicará a todo el sistema y suponga que se desconectará accidentalmente o se establecerá en el valor incorrecto en algún momento. es decir, su aplicación no debe enviar seppuku porque algún directorio de configuración se configuró en / y no tiene permisos (o peor, limpie la unidad porque la aplicación se ejecutó como root). O más probablemente, algo como su RAILS_ENV se configuró en test cuando debería haber sido production y nadie se dio cuenta y ahora los usuarios están escribiendo datos en el lugar incorrecto o en /dev/null en cuenta de todos los 500.

Personalmente, me gusta dejar caer los mensajes logger.warn en cualquier momento que retroceda a una variable de entorno para un valor de configuración.

Con su problema preciso, honestamente, probablemente pasaría el valor de configuración para qué entorno comenzar en la línea de comandos.

Answer 2

En mi empresa, en realidad tenemos ambas cosas, en cierto modo.

Tenemos una aplicación de Rails que puede apuntar a una de las muchas instalaciones diferentes de otra pieza de software y usar la API de esa instalación. Para especificar una instalación, se deben establecer alrededor de 5 variables.

Teníamos cada una de estas variables como variables de entorno separadas, pero al establecerlas todas se ponían viejas muy rápido e inevitablemente olvidamos una.

Ahora tenemos una variable de entorno a la que llamamos ENV_TOKEN y tenemos archivos yaml que contienen entradas correspondientes a las variables ENV_TOKEN válidas y código en config/initializers que establece ENV [key] = value.

Digamos que tengo las variables "FOO" y "BAR" que quiero establecer en "uno" y "dos", respectivamente. Podría crear un archivo que contiene yaml:

carolclarinet: 
    FOO: one 
    BAR: two 

y luego me pondría mi entorno ENV_TOKEN variable para carolclarinet y FOO y BAR consiguen el sistema a uno y dos.

No tengo idea si esta es la mejor manera de hacerlo, pero nos funciona.

ETA: Tenga en cuenta que esto es solo para desarrollar y probar, el instalador de nuestro software se encarga de configurar todo esto para que nuestros clientes nunca cambien las variables de entorno.

Answer 3

Después de mucho googlear en vano, discusiones con algunos usuarios de rieles y algunos ataques cerebrales, he realizado cambios en el código de modo que tengo "Un archivo de configuración por modo de raíles, externalizando las configuraciones de la aplicación a un archivo yml, que en mi caso queda fuera del entorno de rieles"

Más detalles de la misma se pueden encontrar en mi blog en http://bit.ly/hpChwl

Gracias a todos por compartir sus pensamientos. Espero que mi solución les interese a todos :)