Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am looking for best practices that big organizations follow for code check-in and validations.

Currently we follow these steps, - Developer writes code - Developer do some initial tests - Code is awaiting validation now - Technical lead reviews the code (possible bugs, see if coding convention is followed etc) - Once approved by technical lead, the code goes in QA state - Once QA approves the code is checked in into the trunk.

We are now moving to a new project and I was looking for some best practices that would ease the process. We have custom made software that maintains the code status.

Thanks, Ali

share|improve this question

It seems like bad practice to me that there are no check-ins until the code is production ready. I would have a production branch and only cut over to it when the code has gone through all of those steps. my version of your process would be something like this:

  • Developer writes code, checks it in.
  • Does initial testing, checks in fixes
  • Code gets reviewed, suggested changes (if any) are checked in.
  • Reviewed by QA, any changes/fixes here are checked in.
  • Code is cut over to the main branch, ready to go run free in the wild.

In your example, it sounds like a check in would only be made once every few days, where checking in is something you should be doing multiple times a day.

share|improve this answer

The code should always be in source control. The new code can be committed to a branch, reviews, changes, improvements are done there.

QA can be build from the branch.

AFter final approval, merge to trunk.

share|improve this answer

I'd agree that code should be checked in as often as possible, but don't allow check ins that would break the build. Continuous integration is a very good tool to use as well IMO. Requiring all checkins pass the build process and unit tests (and even test coverage if possible) is a good way to ensure that people aren't just throwing stuff over the wall.

Prototypes and other long-running features should go into separate branches as needed and could have less strict rules.

share|improve this answer

I agree with the others that only a single check in is not very good. You should check in all the time, unfortunately "Enterprise" VCS seem to make it difficult to check in, which is near-suicide as far as I can tell. Major integration hassles invariably result.

One thing I would add: do a "diff" on the code in version control, and the code about-to-be-checked-in. At the very least, seeing the diff will let you write more cogent check-in comments. Doing a "diff" before check-in can prevent you from overwriting someone else's changes, or other horrible mistakes.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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