Question

We have developed a java website/platform for one of our customers.

The database properties (username, password, etc), are stored in the project's src/main/resources/*.properties e.g database-live.properties, database-dev.properties, database-local.properties

The customer has decided that they would like to open-source their platform, and move from a private bitbucket repository to a open github repository.

This poses a problem, as the private repository has private database properties, that shouldn't be public.

We will therefore not transfer the history from bitbucket, and instead create a clean repo on github, with the users, passwords, etc in the src/main/resources/*.properties as blank properties. The bitbucket repo will then be closed, and the local machine's and live/dev machine's origin will be changed to the github repo.

On the live and dev boxes however, we would still like to be able to git pull from github, and run mvn clean install, but use the correct db details.

What is the best way to go about doing this? Should we just be adding the properties files to .gitignore, and then on the various machine's local repositories, edit the files with the correct details for that environment?

or should we somehow externalize the configuration, and somehow include it when doing the maven build? what would be the best way to do that?

This seems like a common use case, but maybe I am just going about it the wrong way.

Was it helpful?

Solution

We faced a similar issue long time back. Here's what we ended up doing:

We generalized the config files, with ample examples and comments to indicate what each item will represent. Trying to make it easy for someone trying it out for the first time, to understand what each stands for, and how it affects the behaviour of the application.

Then we maintained a separate repo, lets say deployment-configs, just for the config files that will go into deployment. It contains all the xml files and properties files that contains configuration data, usernames and passwords, etc.

Then we worked on the app with local variables. During deployment, the deployment scripts would pull out the config files from deployment-configs repo and replace it with the config files from the application repository.

At the end of the day, we didn't open source it. But we successfully ended up separating config files with actual values out of the app repo.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top