Question

My team has been working, for the most part, on our own projects. I write the code, check it in to source control, and rarely does anyone else see it (except the end product). Everyone else follows the same basic flow.

The team is starting to grow as are the projects we work on. We will soon need to start coding together on projects. The new guy has been less than successful in his attempts to follow any check-in process, resulting in broken builds.

Some of us have been talking about documenting our process as a first step to ensuring we’re all on the same page. This would be light reading, not necessarily detailed “click this, type this, now click that” kind of stuff. For example, our first process doc would be “How to check in your code”.

In my mind, the process would be similiar to…

1. Before check-in, confirm your code builds AND executes locally.
2. Get latest.
3. Manually resolve any conflicts.
4. Make sure your stuff builds and executes locally using the latest bits retrieved in the above step.
5. Check-in

So, on to the question. What additonal steps are necessary for a good check-in process? Does it really make sense to do something like this? I tend to think so since assuming we all know what to do hasn’t really worked out.

Thanks!

Answer 1

I think the 5 steps you outlined are the minimum that you must do to ensure that the build is not broken.

You will probably want to also run any code verification (unit tests, style cop, fx cop, code formatting) as a final step. You may also want to do code review before commit, or commit to a staging area for review.

You might also want do a clean checkout and build/test afterwards, as this can catch local files which have not been added. This is probably going a step too far if you have a build server, as it will catch this.