Name of the blog

Short description of the blog

New FTP Deployment Service beta

Why using the deployment service?

There is more than one way to get the project files stored in PureCM to a target machine:

  1. Use the PureCM GUI and create a workspace in your target location
  2. Use the command line client to create a workspace in your target location

Both options will create a local copy of the project files on your target machine; so that looks like a perfect way to achieve your goal. In fact, most build tools pull the latest project version that way.

However, both solutions involve installing at least one of the above clients on your target machine, and somehow triggering “update to latest”. ‘Mhmmm, I might not like that for my production environment,’ you say. ‘But I can see that this might be useful for my web developers.’

So this is where the FTP deployment service comes in. Instead of pulling the files to your target location, the deployment service pushes them there. Because it can listen to changes submitted against a stream, it’s capable of deploying them automatically. Stephen has already wrote a nice article on how you could use this service for web development.

How does it work?

The example below shows a possible setup using the FTP deployment server:

  1. A developer submits a change to project 1, which is under source control in PureCM
  2. The development manager merges the change to the deployment stream, which is the base stream for the FTP deployment service. Note that the deployment service can run on the same or a different machine as the PureCM server.
  3. The FTP deployment service listens for changes and gets the change into his workspace.
  4. Only changed files and folders are sent via FTP/SFTP to the target location.

Of course, this is only an example, but I’m sure you get the idea.

Getting the beta download

So now you know about the FTP Deployment Service, why not download the beta and tell us what you think? Is there a feature you miss, or a bug you found? Simply comment this blog or email us your comment to

Learn more >>

Download the FTP deployment service >>

Looking Forward to the 2009-2 Release


2009/1 is only just out of the door but the developers at PureCM have been working on the 2009/2 release for over 3 months now. Some of the big features which you will hear about over the next  few months include our new Visual Studio plug-in and Explorer plug-in. This blog looks at our new ‘Projects’ view. Some of this functionality will find its way into the 2009/2 release but it will not be finished until the 2010/1 release. All functionality is subject to change – but this blog should give you a feel for the direction we are taking PureCM.

The “Problem” with Streams

We believe streams are one of PureCM’s strongest features. One of the reasons for this is that they are flexible so they can be used for a wide variety of functions. For example you can use streams to represent your development branches, user branches, task branches, etc. You can also use streams to create snapshots of your releases. This flexibility, however, brings various problems...

Talking to first-time users we are finding that the concept of a stream can be difficult to grasp. All users are familiar with terms such as versions and releases. Users coming from another SCM tool are familiar with the concepts of branches and snapshots/labels. It can be difficult for users to adjust to the concept that a stream can be used to represent these different entities. Furthermore there is the complexity of having to setup your streams folders to include the relevant permissions.

Another problem with having a generic ‘stream’ is that when listing streams you cannot filter the list according to the context. For example when creating a new workspace, 9 times out of 10 you are creating a workspace for a development branch. It would be great if you could select your workspace stream from a list of these development branches. Currently you have to find the development branch within all the other streams.

This also applies when viewing the Stream Hierarchy Diagram. If you create lots of streams for each release/feature/task/developer then the tree control becomes unreadable (as shown below).


We had a discussion about how we might represent the stream Hierarchy Diagram as a diagram rather than a tree control. It quickly becomes apparent that you want to display development branches differently to releases/snapshots. Furthermore you want the option to show/hide developer/task streams.

Another example is with displaying the child streams in the submitted changes. This is great if you only use streams for development branches and releases. You can quickly see which changesets were submitted between 2 releases. However, if you use streams for feature/task branches then the number of streams shown within the submitted changes becomes unmanageable. It would be nice if you could tell PureCM to only display the release streams within the list of submitted changesets.

Stream Types

So we went back to the drawing board and tried to think of the basic concepts which people use when developing software. So far we have come up with:

  • Project : The project contains all the code for a single project. If you develop multiple projects in PureCM then you have probably created a top level folder for each project.
  • Version : For parallel development it is necessary to create multiple versions of a project..For example we would have a 2009/1 version and a 2009/2 version.
  • Feature : A feature is a large piece of work which is broken up into multiple tasks.
  • Task : A task is a unit of work which requires changing the source files. A task can be created directly from a version or from a feature.
  • Release : Otherwise known as a label or snapshot. This represents an external release, milestone, internal release, etc.


‘Under the hood’ these will all be streams and functionally we are not introducing anything new. But by categorizing streams into these types we can improve the user interface with a new ‘Projects View’.

The Projects View

The Projects View will replace the Streams View in the toolbar. Within the Projects View you will be able to create each of these stream types. Selecting a project, version or feature will list all tasks for that object. So selecting a project will list all the tasks for the whole project. You will be able to filter this list according to the task state (see below). Tasks with a higher priority will appear first in the list.

Tasks or Issues?

 You may be wondering whether tasks are replacing issues. Tasks have a static workflow which is shown here...


The green states are optional while the red states are mandatory. So at its most basic form a user creates the task, a developer starts working on the task and finally the developer submits the task into the version. If you want to plan which tasks will go into which version then you include the ‘Open’ state. If you want a product manager to assign which developer will complete which task (rather than letting the developer choose) the you include the ‘Assigned to Developer State’. If you want to review the developers changes before they are submitted into the version or if you are involved in parallel development then you include the ‘Integrated’ state.

So if the workflow you are using matches the static workflow of tasks then you may be able to replace issues with tasks completely. If your workflow is more complex or if you need to store more information against a task than a simple description then you can use tasks to complement your issue workflow.

The idea is that tasks are lightweight, so they contain a minimum amount of information and need virtually no setup. They do not have custom fields, only a summary. If you want to store more information or have a more detailed workflow then you should use issues to complement the tasks. Alternatively you could use a third party defect tracking tool instead of PureCM issues. Whatever defect tracking tool you choose the tasks will be created automatically and the integration will be seamless.

This concept is illustrated with the PureCM OnTime Bridge which integrated PureCM with OnTime. OnTime stores all the information for a defect/feature/incident. A minimal PureCM issue is created when a developer needs to work on the OnTime defect. When the developer submits the changes the state of the OnTime defect is updated.

What Next?

There are many other advantages which the Projects View brings to PureCM, some of which will be the focus of future blogs...


Creating Merge Paths

When creating a new version, feature or task PureCM will create the relevant merge paths for that stream type.
Maintaining Merge Paths The flat ‘Merging View’ can be reorganized to use the new stream types to make it more user friendly.
Stream Ownership You can specify the user or group which owns the stream. This will make the user interface for ‘My Pending Merges’ a lot better because we can only display the pending merges for streams which you own.
Visual Studio Imagine that you open Visual Studio to get a list of your open tasks. You select a task which automatically creates the workspace if necessary or reuses an existing one to get the project from source control. When you submit your changes the task is automatically closed.

The OnTime Bridge will be updated to use tasks rather than issues, and more integration ‘Bridges’ will be created. If there is a particular defect tracking tool which you use and want to integrate with PureCM then please let us know by emailing

Back from DevWeek

We’re back from DevWeek, and pretty happy to have much less to carry home than on the way to London. DevWeek has been a busy conference again, featuring very insightful sessions according to discussions we had with delegates.

We were happy to get a stand close to the session rooms, catering and registration, which led to a steady flow of visitors trialing our upcoming 2009-1 release. Especially the new GUI and the powerful merging provoked very positive feedback, confirming the comments we got based on the beta during the last weeks.


Obviously, we shouldn’t forget to mention our Wii bowling, where DevWeek attendants showed some highly impressive skills – just have a look at the picture below! We were also able to congratulate two lucky winners with a brand new iPod, and our ‘Bowling Champion’ T-Shirts really were well deserved prizes.

DevWeek has confirmed that it is definitely worth being present at a big SD event, primarily for the numerous and very valuable discussions we were able to have with a wide mix of SCM users. This gives us a better idea about what we can do to improve PureCM. And of course, we were also talking to other exhibitors, such as with Microsoft and IBM Rational on their ALM offerings, or with the developers offering build tools such as TeamCity. Don’t be surprised if you find the latter in a release note in the near future!

Here it is - the PureCM 2009-1 Beta

This update is to highlight that the download links below now point to the latest 2009-1 RC build.


New features

PureCM 2009-1 comes with two major enhancements:

  • Live merge tracking. This powerful feature gives you live and instant transparency about which changes need merging between two streams. Whether you want to push a bug fix back into the development stream or integrate a number of feature streams into your mainline, you can perform all operations directly on your stream without the need to create a workspace. After that, all merges are tracked for full transparency.
  • Task-centric GUI. As a developer, you spend 90% of your time in your workspace. As a manager, your focus is on the project stream. The new task-centric GUI gives you exactly the information you need for your task – not less, and not more.

Further 2009-1 enhancements supporting parallel and distributed development:

  • Workspace Rebasing. Easily switch the content of your workspace to any stream, be it a branch or a snapshot.
  • Deployment Service. Automatically transfer changes to your production environment without installing a PureCM client.
  • PureCM Components. Share libraries across projects to keep them in sync and control change with repository-wide file locking.

Click here to find a more detailed overview about PureCM 2009-1.

How do I best install the PureCM 2009-1 beta?

Note that you need to install both the server and client components of the PureCM beta to test the new features. Depending on your current use of PureCM, you might want to choose one of the following options.

Your current situation

Possible PureCM setup

Download links

I am new to PureCM and have no PureCM components installed yet.

Get the PureCM server and client installer for your OS and follow the on-screen instructions.



Combined client and server

Client installer

Server installer

Eclipse plugin


I am currently evaluating an older version of PureCM, but do not use PureCM for production.

Note that only one version of PureCM can be installed at any one time on a machine. You can thus choose to install the PureCM beta on a clean machine or uninstall your current PureCM version and replace it with the beta.




Please use the links above.

I am already using PureCM for production.

Option 1: You install the PureCM server on a clean machine for testing purposes. Download the .ZIP beta client and run it alongside your current production client when testing (no installation of beta client needed)



Client ZIP

The ZIP client can only be used if you already have a PureCM client installed on your machine.


Please use the links above to download the server component(s).


Option 2: You install both the PureCM server and client on a clean machine for testing purposes.



Please use the links above.


The system requirements are identical to previous PureCM releases and can be found here.  Note that this is a beta product. We would therefore advice that you do not use it on production data.


We are highly interested in getting your feedback, both the good and the bad. This allows us to tailor PureCM’s features to your needs and fix bugs that might have escaped our internal testing. Please send any comment or bug report to, or comment this blog directly. Thank you for your valuable feedback! 


Light Workspace

With the 2009-1 release of PureCM, comes the option of “Light Workspaces”.. The main purpose of Light workspaces was to enable workspace rebasing (see previous blog ‘Towards Rebasing’ October 2008). Currently, each ‘Full’ workspace has a workspace database that contains revision, checkout and file information about the workspace. This is obviously useful information to have, but makes workspaces large and time consuming to recreate. To enable rebasing, we needed to minimise the size of the workspace database. This has been achieved, to the extent that the new workspaces are some 2% of their original size! 

Are Light Workspaces for me?

So now that we have lighter workspaces, what are the benefits and when would you choose to stick with a full workspace? 

The obvious advantage of a light workspace is local disc space – a fraction of the size is required – so recreating a workspace takes a lot less time. Being able to rebase a workspace means you can very quickly switch to a different stream and begin work on it. This is particularly useful when working with many branches, i.e. branch per task patterns.

If you work in an environment that allows a connection to the server most of the time then Light workspaces are ideal as file history can be obtained easily via the repository database on the server. If, however, you work disconnected from the server for a large amount of time, and also require file history then a ‘full’ workspace is still the best option for you. The ability to create local revisions when offline is an advantage of PureCM, as it allows for checkpointing/rollbacks.

Alternatively you could use a light workspace for day to day operation, and also retain a full workspace for retrieving the history of files. This is possible as PureCM allows multiple workspaces, even from the same branch.

How to create a Light Workspace?

When creating a workspace, there is a new option on the creation dialog ‘Store file revisions in the workspace database’ – Uncheck this to create a light workspace. Once the workspace is created, you cannot change this option.

How to rebase a Workspace 

Right click your workspace and choose 'Rebase Workspace'.

The process of rebasing a workspace  uses the same dialog (as the workspace properties) but allows the user to select a different stream. Workspaces can only be rebased if nothing is currently ‘checked out for edit’ in the workspace. Whenever rebasing occurs, the new rebased workspace will automatically become a light workspace.

Using PureCM to Develop Websites

The problem

PureCM was originally designed to help software developers work together to share their code and facilitate parallel development. The last ten years has seen a huge rise in web development which brings with it new ways of working. Although PureCM can be used to store any type of data, if not set up correctly web developers might feel they are fighting against PureCM to work the way they want. This blog outlines some of these different ways of working and how PureCM can be set up to complement them.

Multi-User Workspace

SCM best practices will always advocate having a private workspace where the developer can work independently of his/her colleagues. You choose when to incorporate their changes by updating your workspace – controlling when your work is impacted by other people. You choose when to publish your changes by submitting a changeset – controlling when your colleagues work might be impacted by yours.

In the real world, however, it is not always possible for developers to have private workspaces. This is especially common for web developers where each developer can’t have his/her own version of the website running on their machine. It is therefore not unusual for all web developers to work on a single website on a development server where they all share the same files.

PureCM handles this situation well with multi-user workspaces. An administrator creates a workspace on the development server, the same as creating a private workspace but specifying not to store the workspace in the home directory. Each developer then creates a workspace in the same location, again specifying not to store the workspace in the home directory.

PureCM will automatically recognise that a workspace already exists and will reuse the same workspace. Developers will only see the files they are working on in ‘My Changesets’ (as if they were working within a private workspace). But if another developer checks a file out, the file will become locked to all other developers within that workspace. This stops different developers modifying the same files.



Another area PureCM is improving on is handling non-text based files. While software developers predominantly work with text-based files, a web developer will be much more likely to work with image files and other non-text based files. For the 2008/3 Release PureCM provides support for image viewing and diffing. So developers can see what changes they have made to an image file before submitting.

Not Working in Visual Studio or Eclipse

The majority of software developers use Visual Studio or Eclipse to write applications. Although web developers can use either of these IDEs it is much more common for them to use an alternative IDE. If the IDE doesn’t support the SCC API then the developer has 2 choices; manually checkout a file in PureCM before working on it, or create a writable workspace.

Manually checking out a file becomes very time consuming and is often not practical. If you do a search and replace for a string in 200 files you do not want to go and checkout each file manually. The alternative is to specify that a workspace is writable when creating it.

Now all the files in the workspace are writable – so you can edit them without having to check them out. When you need to submit your edits, run the ‘Check Consistency Wizard’ on the workspace to work out which files have been edited/added/deleted. For convenience you can also enable the ‘Check Consistency before Submit’ option in the Tools | Options | Submit page. Note that this option is client specific, so every developer has to define it for himself.

With this enabled, PureCM will automatically check for edits before every submit. So when you want to submit your work you just press the submit button in your workspace and PureCM will check which files have been changed and launch the ‘Changeset Dialog’ so you can check your changes and then submit.

Websites as Streams

PureCM’s streams based approach is most effective when developing multiple versions of a product simultaneously (parallel development). Typically websites follow a single code path. So why use a powerful tool like PureCM to develop websites?

Firstly most website development involves at least 2 code lines – the development stream and the live stream. So if your web developers manually upload the files they have been working on to the server, they are effectively merging a changeset from the development stream to the live stream. It is not uncommon for web developers to also have intermediary QA (or integration) streams.

In a traditional approach the development and live web sites are on the same server as illustrated here:

In a quality approach the development and live web sites are separated onto different servers:

PureCM will support either approach by using development and live streams. This process will be a lot less error prone (and a lot quicker) if the developer submits the change to the development stream. The change can then be merged to the live stream using the PureCM Resolve Tool and the Web Deployment Server (see below) can then automatically upload the files. PureCM will ensure developers are not treading on each other’s toes.

Another feature our web developer customers have found useful is components. It is typical for a web development company to be developing/maintaining many different websites which share code. So when a bug gets fixed in the shared code they want it applied to all the websites. This is exactly what PureCM components are for. Select a folder in a stream and share it in another stream as a component. The contents of the folder can be changed in either stream and the change will be reflected in the other stream. The PureCM Knowledge Base has lots of articles on when to use components and how to set them up.

Deploying a Website

When a software developer wants to make a new build he/she creates a new release stream, creates a workspace for the release stream on a build machine using PureCM and starts the build process. It is not a problem that PureCM is running on the build machine.

Deploying a web site however is typically a much more secure operation. The web server will typically be tightly controlled with an administrator overseeing exactly which applications are installed on it.

Also, changes to a web site are often uploaded on a daily basis. You do not want the inconvenience of having to go to the web server to update the workspace after every upload.

This is why we are introducing the Web Deployment Server in the 2009-1 release. The web deployment server runs on a separate machine where the PureCM client is installed. It runs as a service listening for submits. When a change is submitted the new files are uploaded to the web server via FTP/SFTP. So PureCM is not installed on the web server and changes are uploaded to the live web site automatically.

What if you want to control which changes are uploaded to the live server and when? You create a separate stream for the live web site. It is only when the product manager merges changes from the development stream to the live stream that they get uploaded to the live web site. Also if you want to rollback a change you can simply rollback the changeset in the development stream and merge it into the live stream.

2009-1 Release and Beyond

With rich internet applications and cloud programming the distinction between a web developer and an application developer is becoming less and less clear. Combined with the increasing adoption of agile development practices, the way developers work is changing dramatically. PureCM is evolving to support these practices with flexible features which support many different ways of working, i.e. offering a future proof solution! A good example of this is the new perspective based GUI.

PureCM Deployment Service

This seems like a good time to tell you of a new feature going to be released early this year, the PureCM Deployment Service. We are always committed to not just looking after your files but also making your daily work flow easier. The deployment service will be a new stand alone service which you can run to automatically transfer files as changes are made over FTP/SFTP to a server of your choice.

Why use it?

This has been designed to enable you to keep your files up to date on a remote server without having to install PureCM on that machine. One practical example of this is keeping a website up to date on your web server.

The PureCM Deployment Service works by listening for changes in your streams using the PureCM Dot Net Client interface and then copying those changes over to the relevant servers. This takes the hassle of keeping your web server up to date away from you, while drastically speeding up the process by only copying the files that have changed. Any changed or added files are sent to the remote location, while file deletes are removed.

How to use it!

The deployment service comes with its own installer and is configured by a simple XML file, which allows you to set up multiple links between different streams and different FTP locations for full flexibility.


The PureCM Deployment Service requires a machine set up with the PureCM client installed and enough space to create workspaces for each of the streams you wish to FTP. This does not have to be on the same machine as the PureCM service.

PureCM 2009-1 Preview

Before we talk features

The first blog in the new year, so first of all my best wishes for 2009! Let me use this fresh start to give you a summarised outlook on PureCM 2009-1, our next major release coming with some rather big changes. So now you might expect a huge list with all the main features, but allow me to make a small detour before getting there...

How you would like to look at your data

If you look at your file system, your data is organised in folders and files. Typically, the highest level folder separates your projects. This is also the approach used by most source control tools such as VSS, SVN or Perforce to structure data in their database. You make changes to a copy of your files or folders, and they get sent back to the database and stored as a new revision.

PureCM uses an additional high level object that includes the files and folders of a project: streams. Streams have two major advantages. First, they remember the relationship between each other, making merging (and merge tracking!) much more transparent. Second, they allow for so called “cheap” snapshots, i.e. branching without making file copies. This allows you to setup your configuration for parallel development, increasing productivity.

Depending on the complexity of your shop, you can create as many (or little) streams as you wish to separate projects, teams, development from maintenance etc... All projects –organised in streams – are stored in the PureCM repository database to keep it safe. You can find some examples later in this blog [anchor].

As a development manager, you need to have all information about your projects at hand. You want to know which changes have gone into a project, which bugfixes need to be merged, or where you are including a specific version of a shared library. So the first big change in PureCM 2009-1 is its repository-centric GUI. To structure the large amount of information present in a repository, the new task-specific views filter the information you need to speed up navigation.

NEW: Task-specific GUI views

As a developer, getting your own sandbox to work on a task in isolation is one of the main views you need, so this is what you get with PureCM 2009-1: the project files and folders, as well as your current changes and all submitted changes to the stream your current workspace is based on. You can thus organise your own changes into changesets, and track the submitted changes from your colleagues you need to integrate.

Note the navigation bar just below the menu bar, which gives you quick access to all the task-specific views. Say you are required to switch to an urgent bugfix and would like to get an overview of your workspaces in this repository, just click on “Workspaces” and select or create the appropriate one.

Likewise, go to the “Streams” view to browse the server, branch your project, and create a release or a stable baseline. You can find out more details about the advantages of the task-specific views in this blog.

Once you have finished a task and would like to move your workspace to the next project or baseline, another new feature in 2009-1 helps you to do this easily: Workspace Rebasing. This feature automatically populates your workspace with the content of any stream you select. No need to delete the existing workspace and create a new one anymore.

NEW: Merge paths for parallel development

Talking of streams actually brings us back to the above discussion about the project structure of a PureCM repository. According to the complexity of your projects, your repository might resemble one of the following (stylised) examples:

In example A, the streams remain typically the same and changes get merged (or promoted) from development to QA to Production. Example B shows a mainline development example with release snapshots, while example C extends the former to a multi-product setup with shared libraries.

You can immediately see that you can use stream folders to organise your streams (or codelines). In this way, you can define permissions on the folder level that get inherited by the streams. This would allow you to define release streams as read only or editable, i.e. used as labels or maintenance branches. In other words, any stream will evolve in isolation or stay static after creation, depending on the stream (folder) policy.

With the new 2009-1 release, you will be able to define Merge Paths between any two streams to track and merge changes in real time. Say you know that you want to keep track of differences between “Feature A” and “Mainline”. Create a Merge Path and you will be able to see at any time, which changes are present in one stream but not in the other, just as in the screenshot below.

This information is also visible in the "Streams" view to highlight pending merges in your stream hierarchy. After merging, the changes get moved to the “Merged changesets” node to track them. Note that all that happens directly on the server, without the need to create a workspace for merging (but you could of course choose to do so as an option).

Using merge paths, you will even be able to define automatic merges! This basically means that any change submitted to the base stream gets instantly merged into the destination stream. In case of conflicts, PureCM automatically moves the change to “Pending Changesets” to allow you to resolve the conflict manually. Of course, one can still choose to make a one-off merge directly on the changeset without defining a merge path.

Feature summary

The essence of the PureCM 2009-1 release is its focus on making work with multiple projects easier. It will not just be easier to work with parallel configurations using Merge Paths and Workspace Rebasing, but also to get the relevant information with the new task-specific views. But before I forget: PureCM obviously gives you more than just that, including advantages like:-

  • Eclipse and Visual Studio integration
  • Proxy Server for distributed teams
  • CruiseControl.NET and FinalBuilder integration
  • Shared libraries between projects (called “Components” in PureCM)
  • Integrated issue management
  • .NET/Java APIs

We will shortly publish the PureCM 2009-1 beta2, which I will certainly announce in this blog. I look forward to getting your feedback once you have been able to play around with it!


PureCM and Continuous Integration - Get Started!

Continuously rising...

Continuous Integration (CI) is one of the most frequently used practises in agile teams nowadays. According to the 3rd annual survey on “The state of agile development”, 65% of the respondents practise CI; up from 50% in 2007. This is little surprising given the advantages of CI.

All these companies are aiming to make integration a non-event in their projects. No big bang integration at the end of a project anymore. No more searching for a bug that was introduced months ago.

The role of source control

So what has PureCM got to do with it? A lot, as CI relies on a source control tool to provide information about changes made (and some more areas, which we will see later on). PureCM makes this particularly transparent, as any change made is a changeset and thus a finished task. To start with a simple example, let us look at the following (mainline development) setup:

Based on this setup, we want to introduce:

  • A mainline build for each submitted change
  • Build and unit test automation
  • Instant build result communication

While automation reduces the overhead of your CI process, team communication is definitely a key element to setup. Continuous Integration works best when a team instantly knows if a change broke the build. So you no longer waste time back-tracking to find out who broke the test doing which change.

With CI, the developer in question instantly needs to fix the change until it compiles and passes the tests. This will actually save time, as the change is still fresh in his mind. Just compare this to the situation where a bug fix is needed for a change introduced several months ago...

CruiseControl.NET server installation

I will base the following on CruiseControl.NET (CC.NET), as this tool is very popular and integrates nicely with PureCM. The first thing you need to do is to setup a clean build machine; you know why ;-). Then install CC.NET, download the PureCM plugin choosing your release and copy it into the CC.NET server directory. You can also find a quick overview about the installation process in our knowledge base.

The all powerful ccnet.config file

The single most important file to configure CC.NET is the... ccnet.config file. In this file, you can define source control integration, used build and test tools, as well as file deployment and notifications. For our example web project, we use the following example file:

<!-- This is your CruiseControl.NET Server Configuration file. Add your projects below! -->

    <name>PureCM Test</name> 

      <intervalTrigger name="continuous" seconds="30" initialSeconds="30"/>


    <sourcecontrol type="purecm">
      <workspace>C:\Documents and Settings\Administrator\My Documents\Example\Development\

      <!-- Use MsBuild to build the .Net solution-->
        <workingDirectory>C:\Documents and Settings\Administrator\My Documents\Example\Development\

      <!-- Use NUnit for unit testing-->
      <nunit path="C:\Program Files\NUnit 2.4.8\bin\nunit-console.exe">
        <!--Path to Visual Studio project executable-->
        <assembly>C:\Documents and Settings\Administrator\My Documents\Example\Development\

      <!-- Email notification to users -->
      <email from="" mailhost="hostname" mailport="25" includeDetails="TRUE" 
           mailhostUsername="username" mailhostPassword="password" useSSL="FALSE" >
          <!-- <user name="LeadDeveloper" group="buildmaster" address=" /> -->
          <!-- <user name="Developer1" group="developers" address=" /> -->
          <!-- <group name="buildmaster" notification="always" /> -->
          <!-- <group name="developers" notification="change" /> -->


(Get this ccnet.config example file)

Let us have a look at the different blocks. We have just an example project, so the entry is pretty short. The <Trigger> tag allows you to define the rhythm with which CC.NET scans for changes, every 30 seconds in this example. Note that CC.NET does not support triggered builds natively, e.g. onSubmit. Now what or where exactly does CruiseControl scan?

In our mainline development example, there is just one PureCM stream where changes get submitted to. So we need to create a workspace in PureCM that allows CruiseControl to retrieve the latest revision, using the same credentials as the CC.NET service. Once set up, this workspace will get updated each time CruiseControl scans for changes, eventually triggering a build.

Obviously, you can move to the next level having a staged stream hierarchy, where CI is performed on each level. But let me talk about that in a later blog.

Setting up the build...

As CC.NET is not a build tool, you need to tell it how it can create builds. This will involve your existing build tool, which is MSBuild in our example. At this point, the config file is complete enough to get the latest changes, compile them and give us feedback about the build status. Using the web dashboard, this looks as follows (no worries, we will get back to unit testing and notifications in a minute).

You can see that each time a change is detected (“IfModificationExists”), CruiseControl.NET uses PureCM’s changeset ID to identify the build. This is where you can see why PureCM changesets are so useful, as each build gets linked to a change that anybody in your team can easily understand, find and potentially... fix.

...and unit testing

However, no CI process is complete without some testing. So we install NUnit (you can get the installers here), write a few test cases and add them to the Visual Studio solution.

Once this is done, we add the reference to the ccnet.config file to include them in the build/test cycle. As NUnit is natively supported in CC.NET, the test results will automatically appear in the web dashboard. This should look like this:


Email notification and the ccTray

As stated initially, you would like to communicate the results of a CI cycle back to your team, so anyone knows whether the mainline is stable or a developer has to fix a recent bug. You can do this via email as in our example, which includes a link to the web dashboard as specified in the <webURL> tag. Alternatively, you can install the ccTray that displays the status of your CI projects in the Windows Taskbar. This instant messenger like service runs real time, so you can get the current status of your CI projects with a glimpse to the lower right of your task bar.

ccTray, image copied from the CruiseControl Wiki

As this blog is getting longer and longer, let me just indicate the link to the CruiseControl online documentation (it is really easy!).

And finally...

So this is it – we are ready to go! I hope that this blog has facilitated your initial CI setup. Of course, the CI process might need some time to become as normal as submitting changes to PureCM for your team  ;-). But try to follow some agile principles like submitting code at least once per day, and you will quickly realise that integration in small and frequent steps not just increases codeline stability, but also productivity. And feel free to let me know about your experiences!

Better Merging - Part 2

Following on from Tim Rutter’s article ‘Better Merging – Part 1’, we have looked at how to improve the merging capability of the tool even further by introducing Merge Paths and a Merging perspective for the 2009-1 release (see Stephen Worthington’s blog on perspectives – ‘PureCM gets a complete makeover’). This is especially useful if you have a staging hierarchy, eg. Development, QA, Release. In such a situation, pushing changes to the next level becomes very transparent. There are many benefits from introducing these merging features, here are the key ones:

Centralized location

A new Merging Perspective provides a central location where users can easily see which changesets have been merged between streams as well being able to carry out required merges. From here users can create new merge paths and see all existing ones. A merge path consists of 4 nodes:

Merged Changesets – Here you can see which changes have been merged from the source stream to the destination stream.

Pending Changesets – Changes that have failed the quick merge process will end up here, allowing you to carry out a full merge, resolving any conflicts (see "Better Merging – Part 1" blog). Changesets can be moved here directly, from ‘Unchanged Changesets’ or all changesets could be moved here for certain types of merge paths. We’re going to introduce an option that would force all changes to become pending for the path. So for example if you have created a child stream and you know you want all the changes that will be submitted to the parent then it makes sense to make all the changesets pending.

Unmerged Changesets – All changes that have been submitted to the source stream, but have not yet been merged to the destination stream are shown here, with functionality to carry out the merge, move to pending, or move to excluded.

Excluded Changesets – When a changeset should not be merged to the destination stream, it can be placed here, helping other users to avoid performing unwanted merges.

Creating the Merge Path..

The display name can be edited to provide a friendly name.

Automatic Merging

Automatic merging optionally takes place when changes are submitted to a stream. So for example, if multiple streams exist that are based on one ‘main’ stream, and it is important that these streams are kept up to date with Main, then a merge path could be created for each of these, with the option to ‘automatically  merge’ switched on (ie Main -> Stream1, Main -> Stream2 etc). This would result in the submitted changes being quick merged to the other streams at the time of the submit. If the quick merge fails, due to conflicts, the changesets would then appear under the Merge Path node as a pending change.

When working with automatic merging, Continuous Integration becomes a very useful practice to control code quality, so look out for a future blog on Continuous Integration...

Further usability improvements

We’re well underway in the development of these new features but have plans for more usability features:

Allowing one off merges to take place from the Merge perspective is an idea we are considering – so rather than having to navigate to a stream, or Workspace, you should be able to use the Merging perspective to do any merge. A ‘My Pending Merges’ node will be useful for developers who have submitted a change to a stream and then need to merge to other streams. This will list only their changesets that need merging. An ‘All Pending Merges’ node will be useful for managers or administrators responsible for overall merging to quickly see what needs merging.

We’re always open to suggestions or ideas so if you have any regarding merge paths, or merging in general, please let us know.