CODEWITHSUNDEEP
jenkinscontinuous-integration
Daud
Daud

Reputation: 7877

What's the right way to provide server-specific configuration files in Jenkins or CI in general?

In CI, we usually take out a fresh copy, and changes in the repository are detected and build started. But in some cases, the local repositories at various servers have different values for some constants in their configuration files that is specific to each server (the mailing address might be different, or logging is enabled/disabled at a particular server).

My question is what's the best way to handle these changes in the CI philosophy, whether, after taking out a fresh copy at each server, server-related changes should be made manually (once) and then we should follow the normal procedure of detecting changes to the repository through SVN

Upvotes: 2

Views: 107

Answers (1)

Slav
Slav

Reputation: 27485

Here is how I do it at my workplace:

I keep configuration files in SVN, per environment, per server type. It goes something like this - DEVPROJ1
--- API
----- api_config_file
--- WEB
----- web_config_file
- QAPROJ1
--- API
----- api_config_file
--- WEB
----- web_config_file
- PRODPROJ1
--- API
----- api_config_file
--- WEB
----- web_config_file

This way, all API servers on PROD will use the configuration file from SVN at PRODPROJ1/API/api_config_file, while all API servers on DEV will use the configuration file from SVN at DEVPROJ1/API/api_config_file.

My deployment scripts than deploy to each server taking environment specific configuration into account. This is achieved simply by telling the deployment script:
Deploy to API:PRODPROJ1=10.0.0.1,API:PRODPROJ1=10.0.0.2. The script then takes API configuration from PRODPROJ1 in SVN.

As you can see, i use generic config file for all APIs. There are times when each API needs specific changes, for example local IP address. These are substituted by the deployment script at install time. You can use a similar approach, but instead of separating them by environment (DEVPROJ1, QAPROJ1), you can separate them by IP address, or machine name.

In either way, i much prefer to have all my configs in the SVN, where changes can be easily tracked and verified, rather than hunting down for individual modifications on random servers.

Of course, maintaining these config files becomes a manual process.

Upvotes: 1

Related Questions