32

I've always worked with the Continuous Integration (CI) build in TFS. However, in my last project we started to use the gated check-in trigger.

Are there any disadvantages when using a gated check-in? Because if it prevents the team from checking in broken code, what's the purpose of a CI trigger?

mguassa
  • 4,051
  • 2
  • 14
  • 19
Danilo Ruziska
  • 457
  • 2
  • 6
  • 13

2 Answers2

52

Gated checkin is a form of continuous integration build. In TFS, it creates a shelveset containing the code that's being validated, then runs a build of that code. Only if that code builds successfully and all configured unit tests pass does the code actually get committed.

Continuous integration is different -- in CI, the code is committed regardless of what happens as a result of the build. If a CI build fails due to bad code being committed, the code is still there, in source control, available for everyone to grab.

Now for the opinion-based part: Gated checkin is great if you have a large number of developers of varying levels of skill/experience, since it prevents broken code from going into source control. The downside is that it increases the time between code being committed and code being available for others, and thus can lead to situations where people are sitting around twiddling their thumbs waiting for the build to complete successfully.

I recommend using gated check-in as a stopgap. If you have a ton of gated check-in build failing, then it's doing its job and preventing bad code from getting committed. If, over time, the team matures and gated check-in builds fail infrequently, then it's serving less purpose and should be switched over to continuous integration and correcting failing builds as they come, instead of delaying every commit in the off chance there's a problem.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
  • 1
    An additional consideration. If the build infrastructure is not available, gated checkin will stop developers from publishing their code; so, I suggest to have a plan B (could be a couple of scripts that change the type of build from Gated to CI and back) – Giulio Vian Jul 29 '15 at 12:38
  • 2
    If you are using Git, you can use build policies to achieve a similar gated checkin workflow: https://msdn.microsoft.com/Library/vs/alm/Code/git/branch-policies#Requirethepullrequesttobuild – Buck Hodges Mar 21 '16 at 13:28
  • 2
    Clarify, people don't have to wait around for GC to complete ("twiddling their thumbs waiting"). They can choose to not preserve their changes locally and continue on their next task. Of course, if they are dependent on that piece, they can keep their local changes and continue, and after the GC is done, they can get latest and reconcile their server/local changes. We do it this way and it keeps people from waiting, and keeps the GC a stop-gap as indicated. – SnapJag Jul 28 '17 at 17:10
  • 2
    @SnapJag While true, I find that *in practice* the shelving/unshelving workflow is cumbersome enough to result in thumb-twiddling. If the build is going to run for 5 minutes and has a risk of getting rejected, I'm going to be reluctant to switch contexts and start working on something else. – Daniel Mann Jul 28 '17 at 17:18
  • 1
    And so you've defined your own scenario and work flow. Others may find my information helpful to know that a downside is not the rule. Our work flow works great and we don't wait for builds to finish. Our builds and unit tests are longer than 5mins. We also perform building and testing just before checkin which keeps GC efficient and predictable. Good luck on your workflow. There are lots of ways to work through scenarios. – SnapJag Jul 28 '17 at 18:04
  • I don't like this answer much especially the recommendation. There are a lot of ways you can achieve some of the objectives outlined above but putting a gated check-in on branches that are part of the pipeline for production is always a good Ideal. Why let anyone check in code that will break your production bound code? Use Gated Check Ins on your main / trunk / prod branch. Use CI on branches below that Dev / feature branches / personal branches etc.. If you use only one branch then use GCI and don't worry about thumb twiddling (within reason). Developers need time to think . – Noel Oct 04 '18 at 19:46
6

Gated check-ins are fundamentally flawed because they validate dirty local state, not versioned state, so they cannot replace independent checks based on a clean slate (such as in a CI pipeline). Similarly QA often needs to be done with a matrix of environments (different compiler version, different browsers, different OS, ...), the cost to set up are better invested in a central CI.

Gated checkins also make committing harder and slower. That is commonly a bad thing, because:

  • In TDD, members should be able to push commits with failing tests
  • Reporting bugs as failing tests is super useful
  • When cooperating on a WIP (work in progress) branch, members should be able to push dirty changes to make them available quickly to others
  • When working on a big change, it can be useful to let other members review unfinished work before investing the time to finish
  • Many people like regularly committing incomplete work as a form of snapshot/backup
  • committing incomplete work is great when frequently switching between branches (stashing only of limited help in particular for new files)
  • QA cannot be time-limited, but committing should not take long

So scenarios where gated checked are ok as workaround or quick and dirty mitigation:

  • Your VCS makes branching hard, or your company does not allow branching
  • The project is tiny
  • Only one developer
  • No CI present
  • Only specific long-lived branches are protected by the gates (but that's not an alternative to CI)
tkruse
  • 10,222
  • 7
  • 53
  • 80
  • 1
    A lot of these drawbacks are mitigated by not enforcing the gate on all branches. – Jeff Mar 05 '19 at 23:29
  • 2
    Feel free to add an answer explaining a useful branch strategy with that distinction – tkruse Mar 06 '19 at 02:32
  • 1
    Many of the downsides mentionned here can be mitigated by shelving (mostly code review and context switching) – bkqc Nov 15 '19 at 17:48
  • 2
    Just 1 point to consider: Never underestimate the power of new developers messing up with your repository. Gated Checkins are simply invaluable for large scale development, regardless of the build waiting time. – sɐunıɔןɐqɐp Feb 26 '20 at 09:06