Java webapps y opensourcing proyecto existente a github – files de properties

Hemos desarrollado un website / plataforma de Java para uno de nuestros clientes.

Las properties de la database (nombre de usuario, contraseña, etc.) se almacenan en las src/main/resources/*.properties por ejemplo, database-live.properties, database-dev.properties, database-local.properties

El cliente ha decidido que le gustaría abrir su plataforma y pasar de un repository de bitbucket privado a un repository de Github abierto.

Esto plantea un problema, ya que el repository privado tiene properties de bases de datos privadas, que no deberían ser públicas.

Por lo tanto, no transferiremos el historial de bitbucket, y en su lugar crearemos un repository limpio en github, con los usuarios, passwords, etc. en las src/main/resources/*.properties Como src/main/resources/*.properties en blanco. El repository bitbucket se cerrará y el origen de la máquina local y de la máquina dev / en vivo se cambiará al repository github.

Sin embargo, en los cuadros live y dev, aún nos gustaría poder download desde github y ejecutar mvn clean install , pero use los datos de db correctos.

¿Cuál es la mejor manera de hacer esto? ¿Deberíamos simplemente agregar los files de properties a .gitignore , y luego en los repositorys locales de las distintas máquinas, editar los files con los detalles correctos para ese entorno?

o deberíamos de alguna manera externalizar la configuration, y de alguna manera includela al hacer la construcción maven? ¿cuál sería la mejor manera de hacer eso?

Esto parece un caso de uso común, pero tal vez lo estoy haciendo de la manera incorrecta.

Nos enfrentamos a un problema similar hace mucho time. Esto es lo que terminamos haciendo:

Se generalizaron los files de configuration, con amplios ejemplos y comentarios para indicar qué representará cada elemento. Tratando de facilitar que alguien lo pruebe por primera vez, para comprender lo que cada uno defiende y cómo afecta el comportamiento de la aplicación.

Luego mantuvimos un repository por separado, digamos deployment-configs, solo para los files de configuration que entrarán en implementación. Contiene todos los files xml y files de properties que contienen datos de configuration, nombres de usuario y passwords, etc.

Luego trabajamos en la aplicación con variables locales. Durante la implementación, las secuencias de commands de deployment extraerían los files de configuration del repository deployment-configs y lo replaceían con los files de configuration del repository de la aplicación.

Al final del día, no abrimos la fuente. Pero terminamos separando con éxito los files de configuration con los valores reales del repository de la aplicación.