Reduce la cantidad de archivos de configuración a la menor cantidad posible

Question

Para la mayoría de mis aplicaciones utilizo iBatis.Net para el acceso/modelado de bases de datos y log4Net para el registro. Al hacer esto, necesito una cantidad de archivos * .config para cada proyecto. Por ejemplo, para una sencilla aplicación que necesita tener los siguientes archivos * .config: (. [AssemblyName] [Extensión] .config)

• app.config
• [AssemblyName] .SqlMap.config
• [AssemblyName] .log4Net.config
• [AssemblyName] .SqlMapProperties.config
• providers.config

Cuando estas aplicaciones van desde DEV probar para PRODUCCIÓN entornos, las configuraciones contenidas en estos archivos cambian según el entorno.

Cuando el número de archivos se agrava teniendo 5-10 (o más) ejecutables compatibles por proyecto, la carga de trabajo en el equipo de infraestructura (los que realizan implementaciones en los diferentes entornos) es bastante alta. También tenemos un alto riesgo de que uno de los archivos de configuración se pierda, o un error en el archivo de configuración.

¿Cuál es la mejor manera de evitar estos riesgos? ¿Debo combinar todos los archivos de configuración en un solo archivo? (¿Es posible con iBatis?) Sé que con VisualStudio 2010 introducen transformaciones para estos archivos de configuración que permiten al desarrollador configurar todos los ajustes para los diferentes entornos y luego dinámicamente (dependiendo de la construcción iniciada) los archivos de configuración se actualizan a las versiones correctas. (VS 2010 - transforms)

Gracias por cualquier ayuda que pueda proporcionar.

Answer 1

Se podía alterar la principal * archivo .config (por ejemplo web.config o app.config) mediante la adición de secciones de configuración

que estoy usando log4net, Active Record y Ciphersafe en una de mi aplicación web y en mi web .config Tengo

<configuration> 
... 
<configSections> 
     <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/> 
      <section name="activerecord" type="Castle.ActiveRecord.Framework.Config.ActiveRecordSectionHandler, Castle.ActiveRecord" /> 
      <section name="cipherSafeConfigSection" type="Obviex.CipherSafe.AppConfigSectionHandler,CipherSafe" /> 
    </configSections> 
... 
</configuration> 

Luego tengo la sección de configuración para cada uno, por ejemplo para log4net tengo

<configuration> 
... 
<log4net> 
     <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender"> 
      <file value="Logs\\TimeRegWeb.log"/> 
      <appendToFile value="true"/> 
      <datePattern value="yyyyMMdd"/> 
      <rollingStyle value="Date"/> 
      <filter type="log4net.Filter.LevelRangeFilter"> 
       <acceptOnMatch value="true"/> 
       <levelMin value="DEBUG"/> 
       <levelMax value="FATAL"/> 
      </filter> 
      <layout type="log4net.Layout.PatternLayout"> 
       <conversionPattern value="%-5p %d %5rms %-22.22c{1} %-18.18M - %m%n"/> 
      </layout> 
     </appender> 
     <root> 
      <level value="DEBUG"/> 
      <appender-ref ref="RollingLogFileAppender"/> 
     </root> 
    </log4net> 
... 
</configuration> 

De esa manera solo tengo 1 archivo web.config. Luego creé un Proyecto separado en mi nombre de solución ProjectFiles que contiene todos mis ensambles externos y archivos de configuración. Luego, cuando solicito actualizar mi solución al lado de las operaciones, copio el archivo de configuración relevante (prueba o prod) con los archivos de la aplicación web

Answer 2

Otra forma es tener los archivos de configuración creados en la compilación o implementar el tiempo utilizando algo como un script AWK o XSLT en combinación con un solo archivo que contiene la configuración específica para cada entorno.

ANT tiene complementos que permiten esto, es probable que otras herramientas de compilación también lo hagan o permitan que se conecten con una API bien publicada.

Por ejemplo, usted podría tener un archivo de plantilla de leer algo así como

database.uri=@@dbUri 
database.user=@@dbUser 
database.credentials=@@dbCredentials 

y para cada entorno de un archivo de esas etiquetas se toman de como

dbUri=jdbc:oracle:10.1.1.10:1224:ORCL 
dbUser=Scott 
dbCredentials=Tiger 

El ambiente que se desplegarán tendría que ser proporcionado al script de compilación de alguna manera, por supuesto, pero debe hacer eso de todos modos.