plataforma Java: ¿Cómo gestionar los valores de configuración para cada desarrollador

Question

Inspirado por esta pregunta:

How to manage Configuration Settings for each Developer

¿Cómo puedo gestionar los ajustes de configuración de aplicación que se deben establecer para cada desarrollador sin comprobar ellos en control de código fuente en la plataforma Java?

Por ejemplo, este es el tipo de cosas que estamos haciendo ahora:

• configuración del origen de datos se almacena en un archivo XML de configuración de la primavera.

• Actualmente, cada desarrollador edita el archivo y hace todo lo posible para no comprometer ese archivo en el control de código fuente. Varios de nosotros tenemos parches (archivos diff) que se aplican al código antes de realizar pruebas en nuestra base de datos local y eliminar el parche antes de verificar el código. Otros desarrolladores editan y revierten los archivos de configuración a mano.

• Lamentablemente, los parches están desactualizados. A veces las personas olvidan revertir su configuración local antes de comprometerse.

Mi pregunta, sin embargo, no está limitada a la configuración de conexión de la base de datos. Me gustaría encontrar una solución donde cada desarrollador pueda anular la configuración de la aplicación sin tener que alterar los archivos controlados por la fuente.

Si hay que cambiar la forma en la que estamos almacenando los parámetros de configuración, entonces creo que deberíamos hacerlo (tal vez JNDI ?, archivos de configuración externos en un camino bien conocido ?, no sé)

¿Qué harías/has hecho?

Answer 1

Coloque el archivo de configuración en un directorio externo. Si no está presente, lea un archivo de configuración predeterminado. El directorio externo puede ser configurable y puede tener un valor predeterminado, por ejemplo c:\workspace\config.

Opcionalmente, durante la construcción, puede copiar las propiedades externas en el artefacto de construcción.

Answer 2

El mejor lugar para tener esta configuración es una base de datos. Y agregue algunas líneas a su código de producción solo para leer estas configuraciones. No significa daño siempre que el propósito se resuelva y todo sea consistente y coherente. Póngase un pequeño marco que lea estas configuraciones y anule las predeterminadas que aparecen en la producción.

Afortunadamente algunos de los frameworks como Rails proporcionan estos y estoy bastante seguro de que también es flexible en Java.

Answer 3

Una cosa que hemos hecho aquí es tener un cargador de propiedades que compruebe primero las propiedades del sistema.

p. Ej. tiene una propiedad llamada datasource.url que se carga en su archivo Spring.

Extendimos el ResourceLoader para verificar primero las propiedades del sistema para ver si había una propiedad con ese nombre y, de ser así, lo cargaría en lugar de usar el valor del archivo de propiedades. (De hecho, creo que Spring's ResourceBundleMessageSource lo hace de manera inmediata si lo configura, pero queríamos un comportamiento personalizado en el que no voy a entrar).

Por lo tanto, si comenzamos nuestra aplicación con unos parámetros de línea de comandos adicionales:

-Ddatasource.url=[local-datasource-url]

Luego se reemplaza el valor del archivo de propiedades.

Obviamente esto es más fácil de hacer para una aplicación Swing (que la nuestra) que una aplicación web, pero todavía existe la posibilidad.

Answer 4

Hacemos que la compilación sea completamente independiente, incluidas cosas como las bases de datos locales H2/Hipersonic/JavaDB y los servidores de correo Ruby. Eso significa que la construcción local no tiene configuración específica del desarrollador y todo apunta a los componentes preempaquetados. También significa que, aparte de los conceptos básicos (JVM, Ruby, Editors), no hay tiempo para configurar un cuadro de desarrollador.

El inconveniente es que el pago del código es algo mayor.

Answer 5

Compruebe un archivo de plantilla (como sample.context.xml) en el control de fuente. Cada desarrollador copia ese archivo a context.xml y hace las modificaciones que le gustan. Si el archivo de configuración real vive en un directorio controlado por fuente, agréguelo a svn: ignore para evitar registros accidentales.

==> Sin confirmaciones accidentales ni configuración de configuración local persistente.

Si falta el archivo de configuración local, la aplicación no se inicia. Esto hace obvio para los nuevos miembros del equipo que las configuraciones pueden configurarse. Obviamente, el servidor de integración continua también necesitará un archivo de configuración local.

En cuanto a dónde colocar esa configuración: Facilita la compilación y la implementación si la configuración específica de la instancia no es parte del archivo .war. Usamos entradas JNDI, que son fáciles de buscar desde los archivos de configuración de primavera usando <j2ee:jndiLookup>.