0

When I have defined a Gated Build, when somebody checks in code the Integration Build field of a work item changes to the Gated Build number (if the developer associates his check in with work items, of course). Once a CI build is triggered this field changes to the CI build number.

My question is: Is there any way of not changing the Integration Build field of a work item once a Gated Build is triggered?

EDIT

Let me be more clear about how we work.

We have several work itens (some are user stories and some are bugs). When a developer checks in code he or she associates his/her check in with those user stories that gets the Resolved state and a "Gated x.x.x.x" in the integration build field. We never test gated builds. Instead, every night we manually trigger a build and those work itens gets updated again, but this time with a "Release x.x.x.x" in the integration build field. In the next day we test those work itens but the process continues and developers keep check in more US or Bugs (that will have the Gated ...).

Sometime we get confused and we test work itens that should not be tested because they are in the "Gated state".

Even if we have branches that will not solve our problem because the developer associates a check in with work itens and we cant change that.

We do not test gated builds because our QA team is small. The dev team have 20 developers and the QA team have only 2. The process of deploy the application takes about 10 minutes and it can be a pain to wait 10 minutes on every developer check in. Also changing the code while we are testing is never a good idea because it can mess up with our test.

Somebody can think that our process is wrong and suggest a new approach. This will be very welcome, but what we do is working very well besides that small issue.

CJBS
  • 15,147
  • 6
  • 86
  • 135
Rafael Colucci
  • 6,018
  • 4
  • 52
  • 121
  • What is it about the gated build that makes you not want the integration build changed to match it? It only changes if the gated build succeeds, right? Also, I don't believe it changes in the case of a private build. – John Saunders Oct 01 '13 at 18:54
  • Are you doing a gated build AND a CI build on the same check-in? – Andrew Clear Oct 01 '13 at 19:01
  • @JohnSaunders It only changes if the gated build changes. I dont want that because sometimes we forget that we should not test gated builds and we test them and they were not published to our QA server – Rafael Colucci Oct 01 '13 at 19:22
  • @AndrewClear No, we are not – Rafael Colucci Oct 01 '13 at 19:22
  • Have you tried creating a custom build number for your gated builds so that you know by looking that the build was just a gated build? Also, why wouldn't you test gated builds? – Andrew Clear Oct 01 '13 at 19:30
  • @AndrewClear I already do that. I dont test gated builds because the process of deploying the app takes about 10 minutes and it would be paitfull to wait anytime somebody checks in code. Also because we can be in the middle of a test and our server is updated to another version (gated) that was just checked in and it can mess up our tests – Rafael Colucci Oct 01 '13 at 19:36
  • @AndrewClear We have 20 developers and only 2 testers. That also makes impossible to test every gated build for the reasons I wrote above. So we accumulate gated builds to test them all. Every night we trigger a CI build and in the next day we test those gated builds. – Rafael Colucci Oct 01 '13 at 19:37
  • So, you're not using CI builds, only gated builds? So when you say, "we don't test gated builds", you're saying, "we don't test every developer check-in". It sounds like you need a separate branch that QA tests. Use the "development" branch to integrate every developer check-in, and don't deploy to the QA servers (_do_ deploy to your DEV servers if you have them). When code is ready to be tested, it can be merged to the "QA" branch and built from there, and those are the versions that QA will test. – John Saunders Oct 01 '13 at 19:49
  • @JohnSaunders We have a gated build and a manual build that is triggered every night as I said before. I like the idea of branching the code, but when the developer checks in code he associates one or more work itens to the ckeck in. Those work itens will be the same we need to test. But those work itens are updated to reflect his check in (the integration build changes). Even if we have branches this will not stop what I am saying to happen. We will keep having the "Gated x.x.x." in our work itens. – Rafael Colucci Oct 01 '13 at 20:22

0 Answers0