¿Cómo diferenciar entre propiedades de prueba y producción en una aplicación?

Question

Estamos desarrollando una gran solución de e-sales J2ee. Tiene muchas integraciones: CMS, ERP, servidor de correo, etc. Todos estos sistemas se dividen en entornos de prueba y producción.

Tenemos que implementar nuestra aplicación en nuestros servidores de prueba con configuración de prueba y cuando se implementa en nuestros servidores de producción, debe usar la configuración de producción. ¿Cómo hacemos que nuestra aplicación seleccione las propiedades correctas?

Lo que hemos tratado hasta ahora es la siguiente:

Todos nuestros archivos de propiedades contienen propiedades de prueba y propiedades de producción

test.mvxapi.server = SERV100TS 
test.mvxapi.username = user 
test.mvxapi.password = password 
test.mvxapi.port = 6006 
test.mvxapi.cono = 600 

mvxapi.server = SERV10001 
mvxapi.username = user 
mvxapi.password = password 
mvxapi.port = 6001 
mvxapi.cono = 100 

El Util que lee estas propiedades tiene un interruptor: isTest() que prefije la clave con "prueba".

public String getProperty(String property) 
{ 
    return properties.getProperty(prefix + "" + property); 
} 

El interruptor está configurado por otra propiedad creada por nuestro servidor de compilación. Cuando se construye .EAR, el script para nuestros servidores de producción inyecta (entrada a build.xml) "isProduction = true" en system.properties.

<propertyfile file="${buildDir}/system.properties"> 
     <entry key="isProduction" value="${systemType}"/> 
    </propertyfile> 

No estoy seguro de si esta es la mejor manera de hacerlo. Si por alguna razón "isProduction = false" se comete de forma incorrecta en nuestro entorno de producción, todo el infierno está perdido.

He leído que las personas tienen propiedades localmente en el servidor. Pero realmente no queremos tener archivos repartidos. Tenemos un clúster de servidores de producción. Asegurarse de que cada servidor tenga el archivo de propiedad correcto no parece seguro

Answer 1

Lo que quiere evitar es tener el archivo de configuración dentro del EAR, el problema es que necesita diferentes EAR para diferentes entornos, y también, cambiar el archivo de configuración requiere una reconstrucción.

En lugar de implementar el mismo EAR a cada servidor, pero configure cada servidor con un recurso URL diferente. iow, agregue un recurso de URL JNDI a todos los servidores que implemente en ese punto en el archivo de configuración para ese recurso. Si ha leído solo el acceso SVN a su repositorio, cree los archivos de configuración en el repositorio svn, o cualquier repositorio al que pueda acceder a través de una URL. Lo bueno aquí es que toda su configuración está centralizada y, por lo tanto, su administración es fácil.

Lo que he hecho (mediante la personalización con resorte) es asegurarme de que JNDI URL recurso opcional. Entonces, si está allí, la aplicación lo usará, si no, no lo hará. La aplicación se inicia ya sea que esté allí o no. De esta forma, incluso cuando se ejecuta sin el recurso JNDI disponible, la aplicación sigue funcionando (entorno de desarrollo, por ejemplo).

Answer 2

No puedo decir si esta es la mejor manera, sin embargo, lo que hacemos es incluir un contenedor de cliente y servidor que aloja las propiedades en consecuencia. Luego incluimos esos frascos en el archivo EAR. Por lo tanto, durante nuestro proceso de compilación incluimos los jar apropiados (QA, TEST, PROD) para el entorno en el que nos estamos desplegando.

El inconveniente es que tenemos que gestionar tres conjuntos de jar de entorno y el equipo de compilación debe tener cuidado de no desplegar el incorrecto. De hecho, sucedió una vez que tuvimos un contenedor PROD desplegado en nuestro entorno de control de calidad y los datos de control de calidad se pusieron en producción ... sí, eso apestaba y era un gran desastre para limpiar.

Estaré viendo esta discusión porque a menudo me pregunto cómo podemos hacer que este proceso sea mejor/más seguro. Great Post +1

Answer 3

¿Despliega un EAR? Luego ponga las propiedades necesarias en JNDI.

Answer 4

En un proyecto anterior de J2EE, hemos estado haciendo exactamente eso. El proceso de compilación (una secuencia de comandos ant) ​​reunió los archivos de configuración correctos, los agregó a un contenedor determinado que luego se insertó en el archivo EAR para entornos de producción, prueba, capacitación, control de calidad, etc.

El nombre del archivo El archivo EAR contenía el nombre del entorno de destino, por lo que era básicamente imposible implementar un archivo en el entorno incorrecto. Si construimos para el objetivo 156p2 (fábrica 156, entorno de producción 2), esto sería parte del nombre del archivo EAR y hormiga incluiría config_156p2.xml. Si el objetivo era incorrecto, el nombre del archivo EAR sería incorrecto y, como última medida de seguridad, el tipo que lo desplegó lo notará.

El archivo de compilación debe contener esto: un objetivo ant para iniciar la compilación para cada entorno que establecería una propiedad que indicara qué archivo de configuración incluir.

La única diferencia entre los archivos EAR serían los archivos de configuración. Todo lo demás era idéntico. Existe la posibilidad, por supuesto, de que alguien haya escrito un valor incorrecto en un archivo de configuración para un entorno determinado. Sin embargo, en la práctica esto nunca sucedió en varios años, incluso con algunos desarrolladores bastante jóvenes y alrededor de quince entornos objetivo (diferentes servidores de pruebas, QA, capacitación y producción en diferentes países).

Answer 5

tenemos 3 carpetas para este propósito en nuestros proyectos, cada uno de ellos contiene los archivos de configuración (nombres de archivo son los mismos entre las carpetas):

• personal: contiene máscaras de poner a prueba db, servidor, etc.
• prueba: contiene rutas de acceso a los servidores compartidos con mis colegas
• producción: contiene ... así lo has adivinado

Cuando construyo mi proyecto añado el perfil adecuado para IntelliJ Id En el módulo deseado, esto significa que estoy agregando una carpeta diferente a la estructura del proyecto, pero debido a que los nombres de archivo son los mismos, los cambios son solo propiedades de perfil.