The last PureCM 2010-1 release has added some very powerful features to PureCM. But how do they relate to day-to-day development? And how to get started? These questions are at the core of our new ‘Solving Development Challenges’ (SDC) blog series that kicks off with this one. So watch out for our SDC blogs to learn about how you can facilitate your software development with PureCM! 

One challenge, one blog

The next blog in a few days time will look at project planning from a project manager’s perspective. Then we’ll take the development manager’s view on configuration management before looking over the shoulders of a developer working on his tasks. Each blog will cover a specific issue and conclude with 3 key lessons. If you are missing a challenge you’d like to know more about let me know by commenting any SDC blog or starting a discussion in our forum. 

Covered topics

We’ll initially focus on challenges within the scope of PureCM Professional, which is quite a bit since the release of 2010-1. The following diagrams give you a quick overview about what’s supported by each PureCM edition. Note that fully included functionality is highlighted in red, while PureCM can also integrate with ‘blue’ tools:

 

                PureCM Professional                                             PureCM Standard

 

To complete this first SDC blog, let me clarify some glossary that will be used throughout the series. This is particularly important when covering the development lifecycle as a whole, with project and development managers working from the same UI in PureCM Professional. These issues will of course be revisited in more detail throughout the blog series.

 

Understanding each other

Topic	Project Manager	Dev Manager
Create or define a release	I define releases to plan (and track) the scope of the next project version that gets shipped to our customers. Thus, I need to be able to schedule the features and fixes that it will contain, typically based on team members' high-level estimates.    è PureCM calls this action ‘creating a version’	When I create a release, I take a snapshot of the current configuration of the project files and folders that was built and shipped. This snapshot (or label/tag) is static, so I can retrieve and rebuild a release at any time.   è PureCM calls this action ‘creating a release’
Using high-level work items such as features or stories	I want to be able to define high-level features to describe new functionality. Development then defines the sub-tasks that are required to complete that feature.     è PureCM uses ‘features’ or ‘folders’ to represent high-level work items. Which one to choose depends on the needs of the development manager.	I want to be able to isolate developer(s) working on a feature on their own branch. That gives me the choice when to integrate it back, i.e. with which iteration or release to ship. But that should be possible with minimal overhead for developers and myself.   è PureCM uses a branch to represent each 'feature' by default. To group multiple tasks without creating a branch, use ‘folders’. Of course, folders can be made features at any time.
Working on multiple releases in parallel	I just need to be able to plan and track multiple project versions at the same time. I might want to distinguish between maintenance and development, but typically I'm more interested in development.   è PureCM allows creating multiple versions for each project, so work items can be scheduled accordingly. è  Version naming is fully customisable.	To be able to support parallel development, I need to work with branches. Typically, I’ve got at least two branches: one for maintenance on a live release, and one for development on the next release.   è PureCM uses a branch to represent each version by default. Of course, this is fully customisable. è Work items scheduled against a specific version automatically populate the developer workspace with the correct project configuration to facilitate communication and avoid errors.

 

The 2010/1 release of PureCM was packed full with so many new features that it is easy to overlook some of the more important ones. So I wanted to focus on one of the new features I am really excited about – features.

Working with Features

 

To create a feature in PureCM open the Projects view, right-click a version and select ‘New Feature’.  From here you will specify the name of the feature and a description. You can see a video of this on the PureCM website.

To start working on the feature go to the My Workspaces view and select ‘Add Workspace’. You can select the feature from the Projects tab.

If you already have a workspace you can switch it to the new feature by selecting ‘Switch’ in the My Workspaces view. This will be very quick and will only change the files which are different.

This has created a new stream for the feature. So you can submit in this workspace without changing the version stream. This is great for checkpointing your code where you can submit incomplete/untested code without breaking everybody else’s workspace.

Having used features for a few months now this has really changed the way I work. I now submit every hour or so. This allows me to try something different safe in the knowledge that I can get back to my previous checkpoint if it doesn’t work out. After completing a piece of work I can also go to one of our testing machines, create/switch a workspace for the feature stream and run the acceptance tests. Only if the acceptance tests pass will I merge the feature changes back into version stream. And I have become more productive because while the acceptance tests are being run on the testing machine I can start working on my next feature.

When I am ready to merge all the feature changes back into the version stream I go to the My Tasks view. The feature is listed under ‘Pending Features’ and I can select ‘Complete’. 

 

 

This will launch the changeset dialog where I can review the edits and submit them as one changeset back into the version. The feature will also be complete – so will no longer appear in the Projects view.

 

Continuous Integration and Feature Streams

 

The simplicity of working with feature streams hides a very powerful aspect to PureCM features – they keep themselves up to date with the version stream. When another developer submits changes to the version stream the changes are automatically merged into your feature stream. So all you have to do is update your workspace.

So you get the best of both worlds. The changes you are making are isolated from other developers, so you can checkpoint your code. But the changes other developers make are being pulled into your feature.

The other advantage with keeping your feature up to date with the version is that merging the feature changes back into the version is trivial. You have already merged the version changes into the feature, so merging the feature changes back into the version is simply a matter of copying the files across.

There are occasions where another developer will submit changes to a file which you have already changed in your feature. This will create an update conflict which will appear in My Tasks and My Workspaces.

 

You can press ‘Resolve’ to launch the Resolve Tool to resolve the conflicts and merge the changeset into the feature.

Guidelines for using Features

As a rule of thumb we recommend you create a feature for any piece of work which takes longer than half a day.

·        Create a new feature

·        Shelve and revert your current changes

·        Switch the workspace to the feature

·        Unshelve the changes into the feature workspace

We are already working on making this process automatic.

Features do not support file locking. So if you cannot allow multiple developers to work on the same files concurrently then features are not appropriate. Cross-stream file locking is something we are hoping to implement for the 2010/2 release.

 

If a feature takes longer than a week then we recommend you perform interim submits back to the version. You can do this in the Project view by right-clicking the feature and selecting ‘Administration | Merged’. This will merge the changes without completing the feature. It is important not to isolate your feature changes from the version for too long if you want to practice continuous integration.

To get the full benefits of features you will need a Professional License. The Standard License will alow you create features but the features will not automatically keep up to date with the version.

Using tasks you can streamline the process of creating and working with features. Please refer to the PureCM Admin Guide for a full explanation of tasks and how they relate to features.

 

 

Any code you write should be submitted within 24 hours. If you have made changes to code on any of your projects which has not been submitted in the last day then you need to read this.

Back to Basics

 

Let’s recap on why it is importance to check code in frequently:

·        Your changes are safe – so they won’t be lost if your laptop breaks.

·        Other people can take over your work – if you have to go on emergency leave.

·        You can rollback changesets – if you want to revert your recent changes.

·        You can identify bugs quicker – isolating a bug to a small change makes it easier to fix.

·        Each changeset describes the code – it is much easier for someone to work out what a piece of code is designed to do if it was submitted in a small self-contained changeset.

I hope we all agree on most (if not all) of these points, otherwise you question why you are using version control at all.

Submitting Unfinished Code

 

One of the golden rules of version control is that you don’t submit unfinished code. You can work in your private workspace to develop and test your code in isolation. When you are finished you submit your changes to the Development Stream.

So if it takes a week to develop and test my changes, I can only submit my changes when it is finished.

Wait. Let’s rephrase that slightly.

So if it takes a week to develop and test my changes, I can only submit my changes to the development stream when it is finished.

You can therefore create a feature stream for your changes. In the feature stream you can submit as often as you want. When you have finished your changes you can merge them all back into the development stream.

Feature Streams are Easy

 

I bet there are some people who stopped reading this as soon as I mentioned the term ‘feature stream’ – development is complicated enough without having feature streams. But let’s break this down and look at why feature streams are perceived as complicated:

·        I’m only going to be working on this change for a week. I can’t be bothered setting up a new stream and everything else.

·        I don’t want the complexity of merging changes to and from the feature stream.

Now let’s look at these 2 points in turn.

Create a Feature Stream in 10 Seconds

 

In the PureCM GUI go to the Repository View. In the folder containing the development stream(s) for this project create a new stream folder and call it ‘Stephen’s Features’.

 

 

Now right-click the development stream and select ‘Create Stream From’. Call the stream ‘Feature A’ and put it in the new stream folder.

 

That is it! For the next feature you won’t even need to do the first step.

You can now right-click a workspace for the development stream and select ‘All Tasks | Rebase Workspace’. This will change your workspace to use your new feature stream. Since the files in the feature stream are currently identical to the files in the development stream the rebase will take no time at all.

Automate Merging to a Feature Stream

 

I lied. It might take 20 seconds to create your first feature stream.

There is another step you should perform after creating the feature stream folder. Right-click the ‘Stephen’s Features’ folder, select Properties and go to the ‘Merge Paths’ page. Uncheck the ‘Inherit Merge Path properties from parent’ checkbox.

Note that this functionality is only available with the Professional Edition. You can use feature streams in the Standard Edition but merging into the feature stream will have to be a manual process. If you are using the Professional Edition then you need to enable the ‘Professional Policies | General | Merge Path Administration’ and ‘Professional Policies | General | Enable Merge Paths’ policies if you have not already done so.

 

OK. I know this dialog can look a bit scary. But just go with me and select the checkboxes as shown above. What this mean is that whenever a changeset is submitted in the development stream it will be applied to the feature stream.

Feature Streams in Action

 

Now the feature streams are all setup, let’s see them in action. In the Repository View delete the old ‘Feature A’ stream (because it was created before we updated the stream folder permissions). Create a ‘Feature B’ stream and rebase your workspace to it.

Now pretend someone else is working on the development stream by creating a workspace for the development stream and submitting a simple changeset. If you now go back to the Feature B workspace you will see that the workspace is out of date and the Submitted Changesets shows the new changeset as outstanding.

Look familiar? The workspace is exactly the same as if you had been working in the development stream. You just need to update your workspace to get the new changes. So as you can see, in the general case where the files you are working on have not been changed by someone else, working in a feature stream is no different to working in the development stream.

Let’s see what happens if another developer changes a file which you have already changed in the feature stream...

Submit a change in the workspace for the feature stream. Remember that the big advantage with feature streams is that the change is not pushed to the server until you say. So this submit could just be a checkpoint of unfinished work.

Now go to the development workspace and submit a change to the same file. You will see that this submit succeeds. This is correct because changes in the feature stream should have no impact on developers working in the development stream.

If you look at the feature stream in the Repository View you will see that it has Pending Merges.

This is telling you that a change was submitted in the development stream which conflicts with changes in the feature stream. Right-click the pending merge changeset and select ‘Merge Change’. This will launch the Resolve Tool – exactly the same as if you had done an update to latest in the development workspace which caused conflicts.

In other words, the only difference between working in the feature stream and working in the development stream is that you need to merge any changesets with conflicts.

You do not even have to go to the Repository View to view your Pending Merges. Within a workspace you can use the menu ‘Workspace | Show Server Files Tab’ to launch a window showing the Pending Merges.

The final piece of the jigsaw is how the submitted changes in the feature stream are pushed to the development stream. Let’s demonstrate this by submitting another changeset in the feature stream workspace. So we now have 2 changes submitted in the feature stream and we want to merge them back to the development stream as a single changeset.

Go back to the Repository View, right-click the development stream and select ‘Merge Changes’. Select the feature stream as the source stream. You will see that only the changesets submitted in the feature stream are listed. Check all of the changesets and press Finish. Don’t choose for PureCM to automatically merge the changesets, because this will merge each changeset individually.

PureCM will then launch the Resolve Tool showing you all of the changes you have made and allowing you to change the description. When you press ‘Save’ the changeset is merged back into the development stream.

So as you can see. The process of pushing the feature stream changes back to the development stream is similar to the process of submitting a changeset. The only difference is that you have the slight overhead of using the Merge Wizard.

Remember that there cannot be conflicts when merging your changes back into the development stream, because you have already merged all the development stream changes into your feature stream. The merge will always be trivial.

Are Feature Streams Worth It?

 

As a developer, if you value the ability to checkpoint your code often so you can revert back to it, then yes I think the small overhead with feature streams will be well worth while.

If not then you might decide that you are happy working without them and only submitting every week or so. But if the day comes when you end up loosing a week’s work because your laptop breaks or your release is late because a developers had to take emergency leave then you might wish that you had been using feature streams.

Wish List

 

PureCM handles features streams well, but there is plenty of room for improvement. Thankfully most (if not all) of these new features will make it into the 2010/1 release (April 2010).

·        Simplify pushing the changes back into the development stream. There should be a toolbar button on the workspace which merges all the changes back into the development stream.

·        Automatically resolve pending merges when updating the feature stream workspace. This functionality would then be identical to when working on the development stream.

·        Distinguish between feature streams and other streams. For example, when displaying the submitted changesets the release streams are very relevant while the feature streams are not.

We often get in contact with people evaluating an SCM tool for the first time. Most of the time, they work in a small team that has grown. So all of a sudden, the “have you finished working on file A?” or “which folder was the latest version in again?” questions don’t work the way they did before. Things get chaotic and errors start to creep in. Valuable time gets lost. So they start looking around for a tool to help them address these issues.

However, implementing SCM is just as much about how to define and set up the processes, as well as addressing resistance to change. Process might be a big word, but questions like “do I need to support multiple releases? If yes, how?” or “how and how often do I create builds and keep track of them?” have to be addressed even for the most basic implementation. This isn’t a bad thing at all, as going through these issues will already pay dividends.

Some resources to get you started

Of course, you can’t spend all your time on researching either. This is where some input in the form of best practices comes in very handy. CM Crossroads, the configuration management portal, has just put together a great set of articles to cover just that. It’s called “SCM Essentials for Small Teams” and gives an excellent overview about common issues and best practices when implementing SCM.

A somewhat more specific approach covering how to enhance responsiveness to change recently appeared on Dr. Dobb’s:  “Everything Changes: How Dev Managers Can Cope With Ever-Shifting Requirements”. It’s been written by Mike Shepherd, who just happens to be a colleague of mine at PureCM. His article covers key best practices that help you dealing with an ever faster rate of change.

That said, responsiveness to change automatically links to Agile, so you might also be interested to learn more about how to support your agile initiative with a sound SCM foundation. There’s a white paper on our website that sheds some light on the link between SCM and agile: "Agile SCM Adoption - 10 Essential Practices".

I hope you can benefit from these resources – enjoy reading!

 

P.S. Feel free to get back to me directly; I’m happy to discuss.

Introduction

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 sales@purecm.com.

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:

<cruisecontrol> <!-- This is your CruiseControl.NET Server Configuration file. Add your projects below! -->   <project>     <name>PureCM Test</name>      <webURL>http://ServerAddress/ccnet/</webURL>       <triggers>        <intervalTrigger name="continuous" seconds="30" initialSeconds="30"/>     </triggers>     <modificationDelaySeconds>2</modificationDelaySeconds>     <sourcecontrol type="purecm">       <workspace>C:\Documents and Settings\Administrator\My Documents\Example\Development\           VSWebExample_CCNET</workspace>     </sourcecontrol>      <tasks>       <!-- Use MsBuild to build the .Net solution-->       <msbuild>         <executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>         <workingDirectory>C:\Documents and Settings\Administrator\My Documents\Example\Development\             VSWebExample_CCNET\VSSampleWebSolution</workingDirectory>         <projectFile>VSSampleWebSolution.sln</projectFile>         <targets>Build</targets>         <timeout>15</timeout>       </msbuild>       <!-- Use NUnit for unit testing-->       <nunit path="C:\Program Files\NUnit 2.4.8\bin\nunit-console.exe">         <assemblies>         <!--Path to Visual Studio project executable-->         <assembly>C:\Documents and Settings\Administrator\My Documents\Example\Development\              VSWebExample_CCNET\VSSampleWebSolution\NUnitClassLibrary\bin\Debug\              NUnitClassLibrary.dll</assembly>         </assemblies>       </nunit>       <!-- Email notification to users -->       <email from="xxx@xxx.com" mailhost="hostname" mailport="25" includeDetails="TRUE"             mailhostUsername="username" mailhostPassword="password" useSSL="FALSE" >         <users>           <!-- <user name="LeadDeveloper" group="buildmaster" address="mailto:aaa@aaa.com /> -->           <!-- <user name="Developer1" group="developers" address="mailto:bbb@bbb.com /> -->         </users>         <groups>           <!-- <group name="buildmaster" notification="always" /> -->           <!-- <group name="developers" notification="change" /> -->         </groups>           </email>     </tasks>   </project> </cruisecontrol>

(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!

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.

 

One of the great strengths of PureCM has always been it's support for parallel development. PureCM's merge functionality allows you to keep track of your changesets and which streams they have been submitted against while making it easy for you to merge these changes into other streams as desired. Now we are looking at making merging even more powerful and simple, but let's first take a look at how merging works today.

Merging Today

The original merge process required you to own a workspace for the stream you are merging into. This gives you a number of benefits such as the ability to easily test each change before submitting it to the server. This is shown as (B) in the lower half of the picture below.

However this process can be time consuming and is hard for manager who may not always have a workspace for each stream. This led to a solution that allows users to quickly merge changes between similar streams, which we called “quick merge”. This allows you to merge changes directly on the server removing the need for a workspace in these situations (A in the picture above).

So far, quick merge will only merge changes where there is no possibility of a conflict. This works well for merging last minute fixes into a release stream or early on in the development cycle when not much has changed in the new development stream but we felt there was a need to improve on this restriction.

Moving Forward

The next stage in this evolution is to allow you to resolve conflicts as part of quick merge without the need for a workspace. This will simply launch the familiar PureCM resolve tool when quick merge finds a conflict.

Combining this new functionality with automated test and build processes (such as PureCM's Cruise Control plug-in) provides a fast and simple way to keep your streams up to date while giving you the security that any errors are picked up immediately so you can assign someone to look at it.

This new advancement to quick merge opens up a realm of possible future features for the tool to help speed up your development process through merging. One example of this is the creation of automatic merge paths to control the flow of your changes through your development streams. Plenty of reasons to look forward to the 2009-1 release – and keep your eyes open for future blogs for information about where we go from here!