Answers: <p>I think you are trying to solve a different issue (environment) with how Git versioning / branching works</p>
  
  <p>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.</p>
  
  <p>There are two ways to solve it, </p>
  
  <p>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)</p>
  
  <p>But drawback in this approach is that each time you add a new environment a new property file gets added to your code</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-08-24T19:35:49.687Z
Answers: and for the "isolate file"  thing you can use git ignore file (https://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.
Answers: Ameen Ibrahim Raffic - 'AIR'
Answers: CC BY-SA 3.0
Answers: 2017-08-25T19:46:30.490Z
Answers: 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.
Answers: nichos
Answers: CC BY-SA 3.0
Answers: 2017-08-24T19:32:55.617Z
Answers: 2017-08-24T19:32:55.617Z
Answers: Ameen Ibrahim Raffic - 'AIR'
Answers: <p>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.</p>
  
  <p>It's true, the file would get merged when a branch merge from the parent is performed. </p>
  
  <p>But often it's a trivial (empty/fast forward) merge - if there were no changes to the msbuild xml file in the parent branch. </p>
  
  <p>And if the merge is not a trivial one it means there were changes in the build process in the parent, which <strong>need</strong> 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 <strong>required</strong> in such case to avoid build breakages.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-08-22T19:23:51.943Z
Answers: 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.
Answers: nichos
Answers: CC BY-SA 3.0
Answers: 2017-08-22T21:58:05.027Z
Answers: 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.
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-08-23T17:02:47.497Z
Answers: 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.
Answers: nichos
Answers: CC BY-SA 3.0
Answers: 2017-08-22T18:43:40.873Z
Answers: 2017-08-22T18:43:40.873Z
Answers: Dan Cornilescu
Body: <p>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).</p>
  
  <p>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.</p>
  
  <p>I also want the build config to stay with the version of the product. So the build.xml will go from develop->QA->release.</p>
  
  <p>How is everyone else handling this?</p>
  
Tags: <jenkins><git><release-management><builds><release>
Title: Where should I store my build configuration files?
UserDisplayName: nichos
ThreadText: # Where should I store my build configuration files?
  
  (Asked by: username_0 on 2017-08-22)
  
  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?
  
  **Tags:** jenkins, git, release-management, builds, release
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-08-24. Score: 0 | Accepted answer
  
  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.
  
  > **Comments:**
  > **username_1**: and for the "isolate file"  thing you can use git ignore file (https://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.  
  > **username_0**: 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.  
  
  ---
  
  ### Answer by username_2 on 2017-08-22. Score: 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.
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_2**: 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.  
  > **username_0**: 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.  
  
  ---
  
  