Continuous Integration using CruiseControl.Net

• Download sample - 18.9 KB

Introduction

I was been assigned a task to automate the build process because we had to spend more time on the builds everyday and at times it proved to be an error prone. So we decided to move over CruiceControl.Net as it easy, free and open source tool.

Prior to automation build we usually had an issue doing manual build by copying files from deployment server to DEV, QA, STAGE and PRODUCTION server and at times we were also frustrated doing more than one build on the same day, it was time consuming, stressful and sometimes not easily repeatable or easy to roll back.

In this article we will learn to setup CI using CruiseControl.Net, so it does everything we ask them to do. CCNet builds occur automatically as changes are detected in source control, it gets the source code from VSS repository, does a build for us, deploy the code to a remote server and finally send us a notification email.

This article is completely for beginners

So, below are the items that I'm going to cover in this article

1. Download and Install CruiseControl.Net

2. Download and Install MSDeploy 2.0

3. Configure CruiseControl.Net

Download and Install CruiseControl.Net

To setup CI, you have to download latest CruiseControl.Net tool and install it on your deployment or local server. After the installation has been completed make sure you

1. CCNET application is available in Internet Information Services (IIS) Manager

2. "CruiseControl.NET Server" has been installed in your Services

Download and Install MSDeploy 2.0

Download and Install MS Deploy version 2.0. Web Deploy (msdeploy) simplifies deployment of Web applications and Web sites to IIS servers. CCNet uses Web Deploy to synchronize IIS servers. You need to install MSdeploy in Deployment Server and Environment Server to sync files.

Configure CruiseControl.Net

All the configuration files we’re going to talk about are placed or are to be placed in

C:\%ProgramFiles%\CruiseControl.NET\server

CruiseControl.NET comes with two executable components: ccservice.exe which is the windows service and ccnet.exe which is a console application that is included for testing purposes. It is much easier to debug a console application than a service, so I strongly recommend you to make your initial tests with ccnet.exe and carefully read the console output to get familiar with CCNet behavior and exceptions.

Moreover both the server component(windows service or console application) look for a file named ccnet.config in which you will place all the actual information needed by CCNet to learn what it is supposed to do and how it is supposed to do.

The below are the configuration block that we are going to configure

1. Project Block
2. Source Control Block
3. Trigger Block
4. Labeller Block
5. Tasks Block
6. Publishers Block

1. Project Block

First of all we need to assign a unique name to the root of the Project Configuration Block: the <project> tag. This Tag would help us to differentiate among other project.

<cruisecontrol>
  <project name="Hello World Sample">
    <artifactDirectory>D:\CruiseControl.Net\Artifact Directory\</artifactDirectory>
    <workingDirectory>D:\CruiseControl.Net\Working Directory\Hello World</workingDirectory>
  </project>
</cruisecontrol>

<ArtifactDirectory>: It use to store the output Log files

<WorkingDirectory>: It contains all the executable files that you may want CruiseControl.NET to execute.

2. Source Control Block

Source Control configuration block tells CCNet that project named ‘Hello World Sample’ is bound to a VSS - Visual Source Safe.

<sourcecontrol type="vss">
      <executable>C:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>
      <project>$/Article/Hello World/HelloWorld</project>
      <username></username>
      <password></password>
      <ssdir>D:\VSS</ssdir>
      <workingDirectory>D:\CruiseControl.Net\Working Directory\Hello World</workingDirectory>
      <cleanCopy>false</cleanCopy>
</sourcecontrol>

This means that the task performed when executing this project depends on the status of that particular VSS repository.

<Executable>: It contains the executable component of VSS.

<Project>: It contains the Directory of the project in VSS.

<Username> and <Password>: To access VSS in order to get the latest copy of it

<ssdir>: It contains the Parent Path of the srcsafe.ini file.

3. Trigger Block

A trigger block is needed to specify when CruiseControl.NET will start a new integration cycle.

We want to check for the repository status continuously so we need an ‘Interval Trigger’ to tell CruiseControl.NET to perform integration periodically after a specified amount of time

<triggers>
  <intervalTrigger name="Subversion" seconds="10" />
</triggers>

The name attribute is used by CruiseControl.NET GUI to identify the trigger that requested the build;
The seconds attribute is the amount of time before triggering the next integration cycle.

Each time the time interval elapses, CCNET checks for modifications and, by default, runs integration only if changes are detected.

4. Labeller Block

A label is created, at each integration cycle; to identify the specific build occurred. Different labellers can be used to generate the label that CCNet will use to track the builds.

Other than the Labeller Blocks that come with the CruiseControl.NET distribution, many people provided plugin Labeller Blocks to target the generation of labels with specific formats.

<labeller type="defaultlabeller">
      <initialBuildLabel>1</initialBuildLabel>
      <prefix>HelloWorld-</prefix>
      <incrementOnFailure>false</incrementOnFailure>
      <labelFormat>00000</labelFormat>
</labeller>

5. Tasks Block

The tasks block represents how the build of the project actually takes place.

<tasks>
      <msbuild>
        <executable>C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe</executable>
        <workingDirectory>D:\CruiseControl.Net\Working Directory\Hello World</workingDirectory>
        <projectFile>Hello World.csproj</projectFile>
        <buildArgs>/t:Build /p:OutDir=D:\\CruiseControl.Net\\PublishedFiles\\;Configuration=Release;UseWPP_CopyWebApplication=True;PipelineDependsOnBuild=False;WarningLevel=0</buildArgs>
        <targets></targets>
        <timeout>900</timeout>
      </msbuild>
      <buildpublisher>
      <sourceDir>D:\CruiseControl.Net\PublishedFiles\_PublishedWebsites\Hello World</sourceDir>
        <publishDir>D:\CruiseControl.Net\Backup</publishDir>
        <useLabelSubDirectory>true</useLabelSubDirectory>
      </buildpublisher>
      <exec>
        <executable>msdeploy.exe</executable>
        <baseDirectory>C:\Program Files\IIS\Microsoft Web Deploy V2</baseDirectory>
        <buildArgs>-verb:sync -source:contentPath=D:\CruiseControl.Net\PublishedFiles\_PublishedWebsites\Hello World -dest:contentPath="Hello World",computerName=YaminPC,username=username,password=password</buildArgs>
      </exec>
</tasks>

We will divide Task Board into 3 parts.

1. Do a build
2. Take a Backup
3. Deploy on remote desktop

a. Do a Build

In our example we will use an MsBuild Task to accomplish the main purpose of our project, which is to compile the versioned Visual Studio project file.

Make sure you provide the output path dir with "\\" slash. Once this task execution is completed you will find the published files in the specified path

Below is the XML definition for MSBuild Task

<executable>: It contains the path to the MSBuild executable file.

<workingDirectory>: It's the directory in which MsBuild will run, so it must be the directory containing our project’s checked out working copy.

<projectFile>: It’s the name of the project to build. MsBuild accepts a Visual Studio solution file as the project file to build. Obviously the MsBuild Task accepts it as well.

<buildArgs>: This row provides additional command line arguments to MsBuild. We would specify the output directory and tell Msbuild to remove the Warning in the code if any.

b. Take a Backup

Once the build is completed you might require taking a back up of it so that if you have any issues in next corresponding build then you can revert the changes with the existing build.

The BuildPublisher task will run only if the MSBuild task runs successfully.

<sourceDIR>: It specify the source of the published files

<publishDIR>: It specifies the destination of the files to be moved.

c. Deploy on remote desktop

After the Build file has been published and backup of it has been taken then last task would be deploying the files on remote desktop. MSDeploy would simplify your job if you provide the right parameter to it.

<Executable>: It’s should be the file name of the MSbuild.exe

<BaseDirectory>: It contains the URL of the Msbuild.

<BuildArgs>: It contains the Arguments to tell MSbuild to perform specific task. The source would tell the place to take the files from and Dest would tell the MSbuild to place the files on respective place.

<sourceDIR>: It specify the source of the published files

<publishDIR>: It specifies the destination of the files to be moved.

If you carefully look into the config file for deployment task you will find "ContentPath", It's nothing but the Web Site name in your IIS Manager or it can be folder path of your remote desktop.

6. Publisher Block

<publishers>
      <xmllogger />
      <statistics />
      <email from="AutoBuild@xxx.com" mailhost="xx.xxx.xxx.xx" mailport="xx" includeDetails="TRUE">
        <users>
          <user name="Yamin" group="buildmaster" address="yaminkhakhu.y@xxx.com" />
          <user name="Khakhu" group="developers" address="yaminkhakhu.y@xxx.com" />
        </users>
        <groups>
          <group name="developers">
            <notifications>
              <notificationType>Fixed</notificationType>
              <notificationType>Success</notificationType>
            </notifications>
          </group>
          <group name="buildmaster">
            <notifications>
              <notificationType>Always</notificationType>
            </notifications>
          </group>
        </groups>
      </email>
    </publishers>

<xmllogger>: is needed for making the web dashboard work correctly.

<statistics>: It collects and updates statistics for each build. You can see them clicking: View Statistics on the left side of the Web Dashboard.

<email>: is used to define the SMTP server configuration

<group>: is used to define the SMTP server configuration

There is also different type of notification available, based on your need you can define them and assign to each of the user group.

Points of Interest

The entire project source that we hold in our Team are been automated for builds.

History

10/07/2014 - Created

10/08/2014 - Updated Broken Images