2

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?

Improve this question

2 Answers 2

Reset to default
0

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.

Improve this answer
2
  • 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, 2017 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, 2017 at 19:46
1

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.

Improve this answer
3
  • 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, 2017 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, 2017 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, 2017 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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