Automating .NET builds using CCNET and TFS
CruiseControl.NET (CCNET) is an open source tool used for continuous builds on server, where testing is required parallel to development. CCNET periodically checks the version control for changes to codebase, builds the source code if any modifications found, publish the build to website hosted location and notifies the build status software stakeholders.
Here I am going to discuss on how to configure the CCNET for continuous builds using TFS as source control.
What you need?
- CCNET Server
- Source Control
CruiseControl.NET is the build server for preparing, publishing builds on server. CCNET pings to the source control for every 30 minutes (this is default value and can be changed in config file) for codebase modifications. You can download and install the CruiseControl.NET from here.
The CCNET comes with web dashboard and server applications.
- Web Dashboard is a web version of CCNET where we can see the build logs, force for the build, stop project, etc.
- Server is a console application for preparing and publishing builds. This server is the heart of build process.
We need to configure the project’s build process in ccnet.config. This file was located in CCNET installation directory. If you install the CCNET in default location, here is the location of config file:
C:\Program Files (x86)\CruiseControl.NET\server\ccnet.config
The configuration file is in XML format with below structure:
- Project (name of the project)
- Source Control (source control details)
- Triggers (interval time for new build [either force build or build on modifications exist] )
- MS Build (building project solution)
- Executable (actions to be done before publishing the code)
- MS Build (publishing project)
- XML Logger (logging integration error, if any)
- Emails (sending emails to developers/others on build status)
Open the configuration file in a notepad or using in your favorite editor and add one more project node as shown below:
The build configuration in CCNET is a little trickier and here are the detailed descriptions for the above figure:
- Name of your project
- Web version of CCNET, and will discuss later in this blog
- Your source control type
- Your TFS local/remote URL
- Username to access TFS project
- Your organization domain where user TFS a/c to be validated
- Project node path from TFS source control
- Working directory of your project
- Triggers the build for given ‘n’ number of seconds
- MSBuild.exe path, which comes with .NET Framework and used for building your solution from working directory
- Name of solution file
- Build arguments
- This is an action to be fired before/after the build. (ex: before publishing the project to target directory, first delete the files from target directory using batch file)
- Name of the project file to be published
- Build arguments along with the output directory, where project to be published
- Log file directory path
That’s all about configuration. Let’s start the ccnet.exe which is available at the same place of ccnet.config and watch out how your project is building, publishing.
Using CCNET you can integrate many source control systems like, TFS, SVN, VSS, Git, ClearCase, etc.
CCTray is a client application used to know all about build statues and can force for builds. You can download the CCTray from here. Also you can download the CCTray from CCNET’s web dashboard.
You can add the project to CCTray using below steps:
- Open CCTray
- Goto File -> Settings, it popup a dialog
- Click on Add button, again it popups another dialog
- Click on Add Server button, once again it popups another dialog
- Now, Add the IP Address where CCNET server was installed and click Ok
- In the back dialog, it shows name of the projects configured on CCNET, select one or more projects and click on Ok and again Ok
- You can see the selected project’s statuses.
CCTray will also give you windows notifications whenever the build success or failed on server.
In my next blog, I will discuss about CCNET’s web version, where you can see more details about each build and build log information. And also we’ll discuss on how to send email notifications to developers or project stakeholder about each build.
Have any questions? Let’s discuss in the comments section below….