Continuous Integration with CodePlex - How, Tricks and Results
As I said in the previous posts, I´m very involved with Project BHAL, mainly because I´m really excited about it and because I love to learn new stuff. And as I also said in my "project envision" post, I´m deploying articles as the releases keep coming.
The series of the First Iteration will be:
- Continuous Integration with CodePlex - How, Tricks and Results
- SandCastle - Yes it works!
- Connection to TFS and WorkItem Creation Helper
- Creating a custom Windows Workflow Foundation Activity
So here is the first of the series.
Continuous Integration with CodePlex - How, Tricks and Results
Introduction
First of all, I want to say that CodePlex is a lot cooler than people give it credit for. Do you guys know how much does a license of a TFS server cost? And how much does it cost to maintain one TFS Server up and running 24/7? A LOT! Now, power it to 100 (or even more) and there you have CodePlex, which Microsoft gives for free! You just have to happen to have a good idea and some spare time. If you come talk to me about how Microsoft doesn´t endorse open software, you are wasting some serious time! And yes, I did thank Microsoft for giving me the space here in CodePlex in a previous post and I´ll probably be thanking them in the future again. Well, thankings apart let´s get to the bad aspects of CodePlex.
The first downside of it comes actually because of a great feature they´ve included in Team Foundation Server and removed from CodePlex. The Team Build engine. If it never existed we would be using CruiseControl happily ever after. But the issue is I got spoiled by Team Build in the TFS environment of the company I work for, and as such I crave for using it in CodePlex. As of the writing of this article, though, CodePlex does not support Team Builds. You are probably thinking that everything is lost and that the Java bad guys won this time, huh? Not so fast buddy! Continuous Integration DOES work with CodePlex, you just have to make some minor adjustments.
When you work with developers that are spread across different countries and that have different timezones, it´s imperative that you have some kind of Continuous Integration mechanism, since they will be checking-in code at different time zones and the only way I can be notified about a check-in that broke the code is with this kind of support.
The other downside is that CodePlex doesn´t support the BisSubscribe tool that handles event subscriptions, but this is beyond the scope of this article. I´ll probably be talking more about the eventing model in future releases of the BHAL project.
As a matter of fact I´ve already told both of these downsides to the CodePlex team and as answer I´ve been told that they´ll be releasing both some time in the future.
But before we start let me state something: This is not a CruiseControl.Net tutorial and by all means I´m sure that there are PLENTY more helpful tutorials about CruiseControl.Net on the web. This tutorial is a helper to get you started into getting CI builds of your CodePlex code.
A lot of this article is based on Martin Woodward´s (Yeah, he always knows everything, I know!) article on CI on CodePlex. I´m only writing this since his article doesn´t show a few minor issues I had.
CI in CodePlex - Requirements
CruiseControl.Net
This tool is the Continuous Integration agent that will build our code in the event of modifications in the codebase (check-in events).
You can get more information about it at http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET.
You can download it at http://confluence.public.thoughtworks.org/display/CCNET/Download.
TFS Source Control Block
This piece of software is what let´s you instruct CruiseControl.Net to get your source code from CodePlex (or any Team Foundation Server for that matter).
You can get this control block from http://prdownloads.sourceforge.net/vstsplugins/ccnet_vsts_plugin_1_2_0_bin.zip?download.
XML Build Logger
Ok, now this was an issue that I had a lot of trouble with. MSBuild uses a XML Build Logger, well, to log how build went. The thing is, that as is the case of any Team Foundation Server module, MSBuild does provide an extensible module. If you use Team Build you get it´s XML Build Logger native, but we aren´t using Team Build, so we have to provide a XML Build Logger. I tried to get the one that Martin pointed out at <logger>ThoughtWorks.CruiseControl.MSBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll</logger> in his article, but at the time I implemented the CI solution it wasn´t available (offline at Thoughtworks website) which was actually kind of cool, since it made me look for other Loggers.
But as I´m writing this I decided to try the Thoughtworks one, and as was expected I had to agree with master Martin (may the force be with you!). The Thoughtworks one is more complete in the sense that it outputs as XML a LOT more information than the other one I found. If you just want the job done, then both will work. I´m including both attached to this post so you can find them easier than I did.
The other one is SedoDream (http://www.codeplex.com/Wiki/View.aspx?ProjectName=Sedodream), which is part of a cool CodePlex project dedicated to building tasks, loggers and other related content (as the site states).
Well, with all that set we´d better get some CI going!
Configuring CruiseControl
I highly recommend that you get CCtray, a Tray application that will keep you posted as of the statuses of any number of CruiseControl project´s builds you have scattered across any number of servers.
Configuring CruiseControl is extremely simple, since everything revolves around one simple configuration file and one Windows Service.
After installing CruiseControl.net head to the Windows Services dialog (Administrative Tools / Services on XP/2003 and TaskManager/Services on Vista), and look for the "CruiseControl.Net" service. Double-Click (or right-click, then properties) and make sure it is as in the following picture:
If it´s not started, start it.
Now head to the folder where your install of CruiseControl.Net is, and inside the /server folder you will find the ccnet.config file. Open it in your editor of preference and edit it like this:
| <cruisecontrol> |
| <project name="BHAL"> |
| <sourcecontrol type="vsts" autoGetSource="true" applyLabel="false"> |
| <server>https://tfs01.codeplex.com</server> |
| <username><<your CodePlex username>></username> |
| <password><<your CodePlex password>></password> |
| <domain>SND.RNO.GBL</domain> |
| <project>$/<<your Team Project>></project> |
| <workingDirectory><<some folder in your drive where you want the version to be downloaded>></workingDirectory> |
| </sourcecontrol> |
| <tasks> |
| <msbuild> |
| <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> |
| <workingDirectory><<Folder where the solution file is>></workingDirectory> |
| <projectFile><<name of the solution file>>.sln</projectFile> |
| <buildArgs>/noconsolelogger /p:Configuration=Release /v:diag</buildArgs> |
| <targets>Build</targets> |
| <!--<logger>Sedodream.MSBuild.Loggers.XmlLogger,C:\Program Files\CruiseControl.NET\server\Sedodream.MSBuild.Loggers.dll</logger>--> |
| <logger>ThoughtWorks.CruiseControl.MSBuild.XmlLogger,C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MSBuild.dll</logger> |
| <timeout>15</timeout> |
| </msbuild> |
| </tasks> |
| <publishers> |
| <xmllogger/> |
| </publishers> |
| </project> |
| </cruisecontrol> |
There are a couple of things to notice here.
You can have as many <project> tags as you like.
The sourcecontrol tag is where you specify your Team Foundation Server configurations. Just remember to change the values I enclosed in << and >> to the appropriate ones.
The <msbuild> task is the one that invokes MSBuild for you. Just replace the tags enclosed in << and >> here as well and you should be fine, except for the <logger> tag. Here you have to specify one valid XmlLogger, so I left both there, but left SedoDream´s one commented. You can choose either, since I´m attaching both here.
The <xmllogger /> attribute is what tells the CruiseControl.Net dashboard that you want the results of the builds in that format.
Ok, now that you have all set open up your CCtray, click File/Settings and add localhost (or the server where you installed CruiseControl.Net) and the Team Project you have chosen in the ccnet.config file. Click ok to save the settings. Now your project appears at the list. Just right-click it and choose Force Build. There you go, if everything went right, and your code is ok, the build should be ok as well.
This is the way I have been using Continuous Integration with CodePlex. Some things I´m considering on improving:
- Generating the latest build in my drive as well as compiling it
- Generating the latest documentation with SandCastle (More on SandCastle in the next article)
- Posting to the Project Wiki when a successful build were made as to specify a nightly build.
Any comments/suggestions please contact me.
