background info on CI

For those who like a bit of background info on CI, there is a lot to find.

Be sure to read these :
THE reference by Martin Fowler
WikiPedia Info

When I started to do CI, some years ago, it was a getting used to at first, but you really learn to appreciate it. Even if one does not do everyting 'by the book' it pays off. When you're in a team, a dedicated buildserver is a must! The bare minimum is doing a compile, so at least know that the source in source control is complete and it is not broken. How many times haven't you heard : 'But it compiles on my pc' ?

At my current work, there was no buildserver, so I set one up. Just to make sure that the code compiles. And now it mostly is. (still using vss for the moment). Next stuff I added was to place some compiled dll's back into source control, so others could get them and uses as references. Before, somebody did a build from his PC, and placed them in source control. This works, but there is no guarantee that the person had the latest sources, or the source he compiled with was in sourcecontrol!

Now, we're also having deployment projects, so placing programs to a Test environment, and from there to QA. Currently we're working on going from QA to Prod, but this is somewhat different. We have about 100 customers, so pushing the programs to every one of them is not an option. For the moment we're thinking of placing them at an external FTP site, and let the customers get them from there, so we only have to upload once.

It is best to slowly add functionality to the build server. When you have a team of people who are not used to working with a source control system, let alone writing tests, you're committing suicide if the buildserver does the following from day 1 :
° compile
° run tests
° run fxcop
° run simian
° run NDepend
and let the build break if one of them throws a warning or error.

bottom line : slowly does it.
It is a change in thinking, and this takes time.