Comments on: One Software Build to Rule Them All https://simpleprogrammer.com/one-build-to-rule-them-all/ Thu, 12 Apr 2018 05:08:17 +0000 hourly 1 https://wordpress.org/?v=7.0 By: Software Developer Skills - The Technical Skills You Need To Have https://simpleprogrammer.com/one-build-to-rule-them-all/#comment-332 Thu, 14 Dec 2017 21:21:55 +0000 https://simpleprogrammer.com/2010/09/03/one-build-to-rule-them-all/#comment-332 […] A sophisticated build system may also run unit tests or user tests, run code quality checks, and provide some reporting on the current state of the code base. […]

]]> By: jsonmez https://simpleprogrammer.com/one-build-to-rule-them-all/#comment-331 Tue, 07 Sep 2010 13:40:18 +0000 https://simpleprogrammer.com/2010/09/03/one-build-to-rule-them-all/#comment-331 In reply to David Keaveny.

Hi David,

What I mean in point 3 is essentially that you end up with one configuration file on that environment that is for that environment.
They way I would recommend doing that is probably similar to what you do. There is no reason you can’t have the file live in source control for each environment.
The key to point 3 is that there be only one place to look for configuration and those differences live in one place in the environment itself.

]]> By: David Keaveny https://simpleprogrammer.com/one-build-to-rule-them-all/#comment-330 Tue, 07 Sep 2010 01:22:52 +0000 https://simpleprogrammer.com/2010/09/03/one-build-to-rule-them-all/#comment-330 Would you mind expanding on point 3? I agree wholeheartedly with points 1 and 2, but I’m not so sure on 3. We keep all our configurations under source control, then part of the build process is to create one build package with the configurations for each environment that the package will be deployed to. Then, when deploying to an environment, all you need to do is copy the appropriate configuration file to the executable folder. You can easily diff the configurations to find out what’s different between environments, and because it’s all under source control, you can check who has changed stuff; you could always do more fancy stuff using a combination of code generation templates and backend configuration databases to generate the configuration files.

If you’re talking about, for example, storing all configuration in the registry, or in a specific location in the file system, how do you manage changes to configuration with a new release (e.g. adding a new connection string), especially across multiple servers if you’re deploying to a server farm?

]]>