Home/ Questions/Q 8796045
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T23:31:52+00:00

In CI, we usually take out a fresh copy, and changes in the repository

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0