Check Out for Continuous Integration

What do you all normally do when checking code out of version control software to perform your continuous integration or nightly build? Do you 1) pull the latest code, or 2) pull by some tag (i.e. FUNCTIONAL) that represents the developer's latest code to be tested?

I guess the answer to this depends on how people normally use their configuration management repositories. Do you intend it to only store code that is "complete". If that is the case, if a developer is working on a task for a week or so, he/she won't be able to check anything in until the task is completely done. If the continuous integration server, however, simply pulled by a well-known tag instead of pulling the latest code, then this would allow devs to check code in very frequently as they are w开发者_开发百科orking to store a history of their work in progress. Then, once they were comfortable with the changes, they could tag their new code with the FUNCTIONAL tag.

Just wanted to know the best practices.

Thanks

So what we usually do is have a "build" branch which the CI server builds off. We merge everything that we want to be included in the nightly build into the build branch and it'll build off there.

We don't actually develop against the build branch tho, we have development branches which are used to keep changes that aren't ready to be released to the test environments.

The main recommendations I'd put out for a CI (more like rules of thumb):

1. Have it to pull code from the HEAD/MASTER. Make your HEAD/MASTER always the latest as possible and as stable as possible.
2. Nobody can commit broken code to the HEAD/MASTER. If that happens, it means that someone broke the build.
3. Whoever breaks the build has to be committed to fix it as soon as possible.
4. Have your CI to run the builds on a per-commit basis. So, as soon as someone commits broken code to the HEAD, the CI will get it and break the build. Most of the CI's servers that I've seen support this modus operandi.
5. You can also have your CI to generate nightly builds and tag the code when they generate the packages. This is also a good practice, and you can see that going on on many CI's from open-source projects around the world.

Some of my experience: Our CI gets to pull the code from the HEAD/MASTER. We use git here, so it's always very easy for our developers to work on branches and keep them synced - but they only get to commit stable code to the HEAD/MASTER.

The right answer is based on how you organize your code.

If the mainline is always supposed to be stable/working, then you simply build from that.

If you have a branch that is the "golden" branch, then...

At our shop, we have three kinds of branches:

• Mainline // always buildable, always "ready to release once QA is done"
• Released branches // golden, released and release-able at any time
• Development branches // where messy surgery gets done

(Of course to do this well takes a good vcs. We use perforce, which has awesome branching.)

We do our continuous building from mainline and release branches.

HTH