1

We have a build pipeline to manage the artifacts' life cycle. The pipline is consist of four stages:

1.commit(runing unit/ingetration tests)
2.at(deploy artifact to at environment and runn automated acceptance tests)
3.uat(deploy artifact to uat environment and run manual acceptance tests) 
4.pt(deploy to pt environment and run performance tests)
5.//TODO we're trying to support the production environment.

The pipeline supports environment varialbles so we can deploy artifacts with different configurations by triggerting with options. The problem is sometimes there are too many configuration items making the deploy script contains too many replacement tasks.

I have an idea of building a centralized configuration managment system (ccm for short name), so we can maintain the configuration items over there and leave only a url(connect to the ccm) replacement task (handling different stages) in the deploy script. Therefore, the artifact doesnt hold the configuration values, it asks the ccm for them.

Is this feasible or a bad idea of the first place?

My concern is that the potential mismatch between the configuration key (defined in the artifact) and value (set in the ccm) is not solved by this solution and may even worse.

Yugang Zhou
  • 7,123
  • 6
  • 32
  • 60

1 Answers1

2

Configuration files should remain with the project or set as configuration variables where they are run. The reasoning behind this is that you're adding a new point of failure in your architecture, you have to take into account that your configuration server could go down thus breaking everything that depends on it.
I would advice against putting yourself in this situation.

There is no problem in having a long list of environment variables defined for a project, besides that could even mean you're doing things properly.

If for some reason you find yourself changing configuration files a lot (for ex. database connection strings, api ednpoints, etc...) then the problem might be this need to change a lot configurations, which should stay almost always the same.

Alberto Zaccagni
  • 30,779
  • 11
  • 72
  • 106
  • I agree with the failure point stuff. Thank you for reminding me that. – Yugang Zhou Jul 08 '13 at 09:28
  • But if the artifact contains configuration value as well as configuration key, it's not easy to use the whole new artifact to replace the old artifact when upgrading because we have to reconfigure all configuration values even if they're not changed. – Yugang Zhou Jul 08 '13 at 09:32
  • What stack are you using? Also, I didnt get your point here, let me make an example and see if that fits: let's say that you have to change a database url, you go and change the value of the corresponding key in the conf file, is this correct? Am I missing something? Consider updating your answer with this added information. – Alberto Zaccagni Jul 08 '13 at 09:35
  • Then I believe that's the smallest amount of work you have to do. If the db connection string changes then you just have to replace it in the proper configuration file. See my updated answer regarding this. – Alberto Zaccagni Jul 08 '13 at 09:54
  • 1
    Usually the configuration files for the various environment are under version control, so that everyone has them, also they are split in files based on the environment so for example if you have a dev environment you will have a dev file which will hold all the configuration values for it, the build system will take care of including it in the war. – Alberto Zaccagni Jul 08 '13 at 10:17
  • This idea sounds interesting, but how does the build system take care of it? If the config file's scm directory is under the root directory of the project, then everytime some one modifies the config, the pipeline will detect it and triggers a build. Sometimes its not necessary for we just want to add a new envrionment. – Yugang Zhou Jul 08 '13 at 10:41
  • For that I think you should open a new question :D If my post answered your question mark it as accepted, otherwise link to it in the new question. – Alberto Zaccagni Jul 08 '13 at 10:42
  • 1
    I would like to leave it open for a while (for more ideas) :P and I opened a new question for more detail about your answer. Here is the link http://stackoverflow.com/questions/17525025/how-to-design-the-build-pipeline-when-the-configs-for-different-environments-are – Yugang Zhou Jul 08 '13 at 11:04