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?


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.

  • and for the "isolate file" thing you can use git ignore file (help.github.com/articles/ignoring-files) and commit it, it will start ignoring any changes to the build fie. But as suggested you need to start implementing environment variables for a dynamic and scalable approach. – Ameen Ibrahim Raffic - 'AIR' Aug 24 '17 at 19:35
  • Thanks. I had considered the env. var thing, but I want to keep as much code out of jenkins as possible which is where i'd have to set the vars before build. Perforce does the isolate thing, that's where I got it from, and github does it with CODEOWNERS. As for b, that's the route I'm currently going now, I have my build.xml in a dir for each build (dev-ops_repo\QA-build\build.xml), but it doesn't seem like it's going to scale too well. – nichos Aug 25 '17 at 19:46

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.

  • The problem with this in our case is that we make modifications to our web.config in the msbuild.xml, which include things like database=beta, prod, etc. Merging from the parent there would cause serious problems. – nichos Aug 22 '17 at 19:23
  • Exactly my point - how often are you changing those? Once per branch lifetime? That's the only time you need to pay attention, at the next merge they won't show in the diffs anymore. – Dan Cornilescu Aug 22 '17 at 21:58
  • They may change a few times each branch. The risk is there's several cooks in the kitchen, and any developer might merge from the parent to keep their team branch in sync. I had looked in to something like "isolate file" in github (like how CODEOWNERS works) but that doesn't seem to exist. That would solve my issue though. – nichos Aug 23 '17 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.