¿Archivo de properties en Git o proyecto externo?

Estamos desarrollando una aplicación web basada en spring que debe implementarse en varios entornos:

1) desarrolladores de máquinas locales con el fin de desarrollar nuevas características \ corregir errores, etc.

2) QA Env # 1 – para que el equipo de control de calidad pruebe nuestros lanzamientos

3) QA Env # 2 – para que el equipo de control de calidad pruebe nuestros lanzamientos

4) QA Env # 3 – para que el equipo de QA pruebe nuestros lanzamientos

5) Producción

Ahora, cada deployment para uno de estos entornos requiere llenar un file de properties, este file contiene muchos parameters:

1) tomcat ips

2) mysql ip

3) mongo ip

4) carga equilibradora ip

5) ehcache múltiples puertos y direcciones.

6) muchos muchos más

Nuestra pregunta es:

¿Dónde debe definirse este file de properties? en nuestra base de código? (git, ¿en una carpeta para cada entorno?) fuera del proyecto webapp (de esta forma, cada entorno debe actualizarse con el file de properties correcto una vez y luego la implementación es sencilla sin configuraciones).

Tenga en count que estamos trabajando en una máquina de compilation / implementación que desplegará automáticamente nuestro proyecto en todos estos envs, por lo que esto es algo a tener en count a la hora de decidir la forma correcta de manejarlo.

En general, no mantendría los files de properties en un repository, aunque estamos hablando de uno privado. Algunas razones que vienen a mi mente son:

  • El control de versiones no es necesario . Personalmente, no veo sentido mantener el historial de versiones de la implementación o los files de properties de control de calidad.

  • Privacidad del cliente Es posible que no desee compartir la configuration de implementación con todas las personas que tienen acceso al repository (desarrolladores, equipo de control de calidad, …).

  • Previniendo errores Los errores suceden Un desarrollador que haya cometido un error al realizar algunos cambios en la implementación o en los files de properties de control de calidad puede ocasionar serios problemas a su cadena de compilation / implementación.

Lo que puede hacer es agregar a su repository algunas templates para los files de properties que contienen una configuration pnetworkingeterminada para su aplicación (por ejemplo, la configuration del desarrollador local ).
Luego puede tener diferentes files de properties para diferentes entornos que distribuya solo dentro de los equipos involucrados (configuration de control de calidad para el equipo de control de calidad, configuration de deployment solo para el sistema desplegado).

Es muy probable que su máquina build \ deploy tenga acceso a todos los files de properties diferentes y pueda recuperar la correcta dependiendo del entorno de destino. Con dicha configuration, no tiene ningún beneficio mantener estos files en el repository, es suficiente almacenarlos en una location disponible para las personas con derecho a cambiarlos y a la máquina build \ deploy.