General background information¶
In order to get the best of these post, we'll need to explain some basic stuff.The following services/roles are needed for a Continuous Integration System:
- developer PC (duh)
- source control server
- build server
- build server visualizer
- issue/bug tracker
Before you start screaming : this costs a lot to set up, remind that these are roles, it does not mean that each role/service has to be on its own server.
That is advised for best performance, but does not have to be. It depends a lot on how many people are working at the same time, the size of the project, ....
For smaller projects you can easily set all this up on 1 server. Hey, I even set this all up once on my developer laptop ( a machine with 4 gig memory).
Get the one you need, specs change so fast these days that providing numbers is not meaningful.
As long as you're comfy with it, it'll do the job :-)
Visual Studio Express and MonoDevelop are great free editors for writing .Net code.
Source Control¶Source control systems come in a lot of variety, and CCNet supports a lot of them : for a list look at Source Control Blocks.
Free and very good ones are svn and git, there are also free providers of these source control systems, so you do not have to maintain these servers/services yourself.
There are probably others as well. Or you can setup the source control system of your choice yourself on a system you choose.
This would be CCNet :-), installed on a server/machine of your choice. Depending on the amount of projects, the size, activity or the kind of actions you do,
one or more build servers can be needed.
Build Server Visualizer¶
This would be CCNet: CCTray and the webDashboard, both can visualize multiple CCNet build servers.
Another nice one is Cradiator This is a WPF-frontend that shows the state of CCNet projects on a big screen, making it ideal to give an overview for a team in the same room.
Even a piece of paper can do this trick, or an excel sheet, but a real issue tracking system is always neat. CCNet has some integration with issue-tracking systems see IssueUrlBuilder
SourceForge also offers issue tracking like Trac and DotProject.
Usages for CCNet¶
CCNet can be used in a variety of setups, I'll list some up that I've setup or heard about, and will provide (detailed) steps to set some up.
This will be the most used setup: get the source from a SourceControl and compile it.
Benefits : you know that the source in your source control is complete (think of 3rd party components)
You can also include testing, source analysis, package creation and so on in CCNet.
And of course you'll have full control on when stuff should be done : on every check in, on set times, nightly builds, ....
Staging Server¶Once you have a setup package, it is very handy that one can install it on a test server. Depending on the type of software and the needed components to update,
this can go from a simple folder to copy (xcopy) to something like :
- create/update a database
- install/update click once apps
- install/update wcf services
- install/update web-sites
- install/update windows services
- install/update SQL-Reports services
and no, I did not make the last one up, this is what CCNet actually does for me (and it does even more).
For the interested ones, you can read more about that in the posts at RuWi
Also you want this to be automated and repeatable, so no manual actions should be needed, hey with the build in security,
you can even configure it that developers can stage it to a test environment, where testers do some visual tests, and from there on it goes to final QA,
where a product owner can give it's final approval, before it goes to production. Developers can not put a package into the QA environment, this has to be done by a tester.
Suppose you do not want to compile source, but do actions at certain times, even here CCNet can help out. There are a lot of triggers built into CCNet.
You can compare this usage with Scheduled Tasks, or the CRON daemon in Linux.
Other cool usages :