Archivos de configuration con nombre: ¿está activo o no?

Elegí una solución para nuestro process de file de configuration y necesito justificarla. Agradecería la comprensión y la crítica. ¡Gracias!

Problema: nuestras aplicaciones web tienen un único file application.cfm que contiene variables y condicionales

<cfif url = "*dev*" or "jargon123"> this is a dev enviroment, do devy things </cfif> 

Entonces, un desarrollador nuevo de la aplicación desplegará una instancia local. Enciéndelo y comienza a hurgar. El problema es que el file de configuration contiene valores de producción. Comienza a get datos de producción y a enviar correos electrónicos de producción. Además, dado que la URL a la que están accediendo es http: // Nombre_aplicación: PORT o http: // localhost : los condicionales dev nunca se establecen. Entonces hay más cosas de producción sucediendo en dev.

Lo que otros compañeros de trabajo quieren:

  • Una statement de cambio. El app.cfm liderará con una variable de entorno establecida en "desarrollo" y luego declarará las variables generales. Luego irá a una statement de cambio y declarará variables específicas del entorno. No estoy de acuerdo con este método ya que algunos de nuestros files de configuration son de 100 a 250 líneas. Esa puede ser una statement de Switch masiva en la que no quiero perder el time.

Mi solución elegida:

  • App.cfm se ha eliminado y eliminado del control de versiones. Ahora tenemos varios files de Applicaiton.Enviroment.cfm, es decir, Applicaiton.Prod.cfm, Application.Dev.cfm, Applicaiton.MyName.cfm, etc. Este file contiene todos los datos específicos del entorno. Cambié la configuration específica de producción de condicionales a App.Prod.cfm. Las implementaciones en nuevos entornos ahora son 1. Duplicar App.Dev.cfm como App.Me.cfm y confirmar. 2. Actualice todas las variables a mis datos personales (correo electrónico, inicio de session, etc.) 3. Duplique App.me.cfm como App.cfm y utilícela para el file de configuration.

No entraré en por qué no estoy haciendo las otras soluciones, pero esta es mi razón para mis soluciones:

  • Obliga al ingeniero de implementación a seleccionar el file de configuration correcto para el entorno. La aplicación no funcionará sin una app.cfm
  • Limita el potencial de error del usuario. El escenario sería un usuario copy datos en un nuevo modo de entorno y accidentalmente copy contenido de producción.
  • Es más limpio y fácil de usar: los valores de configuration están completamente compartimentados.

He encontrado muchos artículos sobre cómo trabajar con files de configuration específicos del entorno, pero no por qué son mejores. Esa es la motivación detrás de esta publicación.

También eliminaría la configuration de producción y solo proporcionaría las versiones de desarrollo del file de configuration. Razones:

  • un file de configuration podría contener datos relevantes de security
  • muchos desarrolladores son simplemente lazzy, si la aplicación se ejecuta, no importa la configuration
  • si el desarrollador no usa los mecanismos proporcionados actualmente (el desarrollador), ¿quién puede estar seguro de que configuren la variable de entorno?
  • el uso de la configuration en vivo durante la testing podría dar como resultado opciones de debugging activas en la producción más tarde (se olvidó eliminar de la configuration)

Usted (desarrollo) necesita poder cambiar entre diferentes configuraciones para diferentes versiones de su software en cualquier momento. Si cada configuration tiene su propio file de configuration, es mucho más fácil que si todos comparten el mismo file.

Si tiene toda la configuration en un solo file, debe leer todo el file grande y decidir qué partes ignorar. Esto es más complicado que solo leer todo el file.

(Supongo que puede tener múltiples versiones del software instaladas simultáneamente en diferentes ubicaciones en la misma máquina. Si no puede, tiene un problema mayor, pero aún así, tener files de configuration separados es beneficioso).

Esos son 'pros' fuertes para files de configuration separados: superan el 'inconveniente' menor: debe identificar dónde se encuentra el file de configuration por algún mecanismo u otro. Puede ser a través de una variable de entorno o mediante una opción de command-line, con un valor pnetworkingeterminado adecuado si no se especifica ninguno. La línea de command debe anular el entorno.

    Intereting Posts