Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm currently on a team that uses post-checkin validation in our developers' workflow:

  1. Developer checks in code (and hopefully runs tests first)
  2. CI machine syncs, builds, run tests
  3. If tests fail, code is already checked in but dev (and related people) are made aware (e.g. mail)

I've seen or read of several teams who instead use pre-checkin validation (aka "gated checkins"):

  1. Dev submits changes (and hopefully runs tests first)
  2. Checkin system builds changes and runs test
  3. If tests fail, changes are not checked in, and dev is informed of test failures.
  4. If tests pass, changes are checked in, and dev is informed.

It seems like there's a couple of tradeoffs between these options, such as the turnaround for developers to know if their code is submitted (post-checkin is immediate, pre-checkin waits for the validation to finish), and the known state of code that is checked in (pre-checkin flushes out all issues found by the validation tests, but post-checkin could allow for easily buggy code to get checked in on the Friday afternoon before the dev goes on vacation).

Is there any reference material on the tradeoffs/benefits between these two approaches? Or any measured research on whether developers are affected by either one? (E.g. developer productivity is interruptions from pre-checkin validation distracting, since their code is not checked in; or, developers with pre-checkin validation tend to find bugs quicker and can turn around high quality features faster).

share|improve this question

closed as off-topic by gnat, MichaelT, jwenting, Bart van Ingen Schenau, mattnz Jun 3 '14 at 7:34

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, MichaelT, jwenting, Bart van Ingen Schenau, mattnz
If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer 1

The important thing is to prevent a bad check-in from slowing all the other developers. Post-check-in validation is fine, as long as other developers do not pick up untested check-ins. This isn't hard. After a check-in is validated, the CI system can just attach a label like "last-good" to the validated code. Then instead of updating to the latest check-in, developers update to the "last-good" check-in. If label creation is expensive (e.g. CVS), it's time to move to a modern version control system.

share|improve this answer

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