Continuous integration workflow idea

Question

Hi,

In the software development environment where I work we have a group of developers all working in the same (Java) codebase (currently using SVN). I notice that people want to commit often what they have constructed without 'breaking the build'. So just for that reason I'm looking at tools like Git and Mercurial that make branching and especially merging much easier.

One of the things I see is that if a developer commits 'bad code' then the code is broken for everyone. As an idea to avoid this I would like a way of having a 'intermediate single feature' repository that is simply the current 'master' with ONLY the one changeset for that single new feature. Such a 'intermediate single feature' repository can then be automatically tested (code quality, unit testing, manual code inspection, etc.) before becoming part of the main code base.

So the workflow I have in mind looks something like this:.

1. A developer creates a new feature and commits this locally on a daily basis.
2. After some time the developer is finished and submits the entire changeset to be integrated into the 'main' repository.
3. A continuous integration system takes the current 'master', applies the changeset and checks the code (merge conflicts, PMD, Findbugs,...), runs the unit tests, checks the coding style, etc.
4. If the CI system decides "bad code" the developer is notified about the reasons and the developer has to fix the mentioned issues. In this case the main repository is unchanged.
5. If the CI system decides "good enough" then the code reaches the 'lead developer' or a 'code reviewer' who inspects the chosen solution and approves or rejects it.
6. The approved changeset is then included into the main repository and is available for all developers to rebase/merge with.

I have some questions about this kind of workflow:

• Do you thing this will work well in practice (i.e. is this a good idea or a really braindead one)?
• Have any of you worked with something like this before? What were the pro's and con's?
• Is there a 'ready to run' script/procedure/tool/... that makes it possible to jump start such a workflow (or a variation on this idea) in minimal time?

Thanks.

---

Background note:

I have worked as a developer some 13 years ago at a company where they build a similar workflow internally and they had two nightly builds:

1. The 'production' version: Main code base
2. The 'senior version: Main code base with all newly submitted versions of all changed files.

Because this was all SCCS (lock-edit-unlock model) based there was no way to 'commit often', you had deadlocks for code changes and all other kinds of nasty effects. What I'm looking for is mainly the good things about what I used back then using the much better tools of today.

Answer 1

At the company I'm currently working we thought about using such an approach. In the end we chose to use something simpler. We let the automated builds set a label after a successful build and we have a tool that we use to sync to that label. So when someone breaks the build, other people will still be able to get a working version from the repository. The tool that syncs also makes sure that if you just submitted something, your changes will not be replaced by the revisions belonging to the label. For us this work perfectly, but it might not be suited for your situation.

Regards,

Sebastiaan

Answer 2

TeamCity has a pretest commit feature.

http://www.jetbrains.com/teamcity/delayed_commit.html