Where should I store my build configuration files?

Question

At my work we use git for our source control, MSBuild for our builds, and Jenkins for our CI. Our git repo will have different branches for the cycle of the product (develop, QA, release).

My question is where should I store the msbuild xml? If I check it in alongside the product, say in develop and there's a feature branch, the file gets merged when a team does a merge from the parent. So that's not an option.

I also want the build config to stay with the version of the product. So the build.xml will go from develop->QA->release.

How is everyone else handling this?

Answer 1

I think you are trying to solve a different issue (environment) with how Git versioning / branching works

As suggested by @Dan you need to keep the build.xml alongside product code but at the same time the build.xml should not change for each environment (database=beta, prod ,qa) etc.

There are two ways to solve it,

a. Make your application dynamic to read system environment variables (like ENV=qa , ENV=beta or ENV=PROD and have different property files for each environment and keep the build.xml static (with just referring the variable)

But drawback in this approach is that each time you add a new environment a new property file gets added to your code

b. Have all the dependent resources (like database end point / credentials , host_name , email server and credentials, . etc) everything into system environmental variables or service startup variable for e.g in JVM it is -D and maintain a separate repo for all the configurations and execute the same using a config management tool like Ansible/Salt , Chef. This way you decouple platform code form configuration / dependent resources and keep the code base rolling with new features without depending upon the environment.

Answer 2

Normally the build configuration needs to stay consistent with the product code, so it should be stored into the same git repo as the product code.

It's true, the file would get merged when a branch merge from the parent is performed.

But often it's a trivial (empty/fast forward) merge - if there were no changes to the msbuild xml file in the parent branch.

And if the merge is not a trivial one it means there were changes in the build process in the parent, which need to be taken into account in the child branch as well since it also picks up the code updates that go with those build changes. In other words the msbuild xml merge is required in such case to avoid build breakages.