Tim has already described how to schedule tasks and features in Part 3 of the series. This blog will build on this to show how you can reschedule a task or feature. This is one of the major benefits to using features – you can choose which version the feature will be completed in. 

For example you might start a feature in Version 1 thinking it will only take a week. The developer working on the feature will submit changes to the feature. If you realize it will take longer than expected you can move the feature to Version 2. Because the developer only submitted changes to the feature, Version 1 was never updated.

Rescheduling Tasks and Features

To reschedule tasks and features, select them in the Projects view and select ‘Move’. This will launch a dialog for you to select the new version. Alternatively you can drag-and-drop them into the version within the Projects tree.

You are not restricted to moving tasks and features between versions. You can move them between features and folders in the same way.

If developers have not started working on the task or feature then this is it. If work has already commenced then the situation becomes a little more complicated... but less so than you might expect!

Work In Progress: Tasks

A developer is working on the task within her workspace so the task appears under Current Tasks with the file changes.

If a manager moves this task to another version the developer will receive a warning that the task has been moved.

When the developer goes to the My Tasks view, she will see that the task is still assigned to her but that it is not currently being worked on.

The developer will press ‘Start’ to begin working on the task and select the existing workspace. This will switch the workspace to the new version while keeping the changes made.

If you are using a release of PureCM prior to 2010-1d you will first need to manually shelve your changes to the server and revert the changes from the original workspace. You will not be able to switch a workspace which contains changes. After switching the workspace you will need to unshelve the changes back into the workspace.

The simplicity of this approach is often overlooked. Before we started using tasks the team leader would tell each developer which version to submit the changes into. So it was the responsibility of the developer to ensure they were working against the correct version. This is both prone to error and time consuming. Now PureCM switches the workspace to the correct version automatically.

Work In Progress: Features

Now, let’s look at the case when a developer has already submitted changes to the feature. PureCM will automatically create a new feature stream from the new version and merge all the changes from the old feature stream into the new feature stream. If the files in which the changes were made are identical between the two versions then this will all happen automatically. If any of the files are different then this will create an update conflict.

If you are using a release of PureCM prior to 2010-1d you will need to create a new feature from the new version. Create a merge rule from the old feature stream to the new feature stream with the auto-merge flag set. Complete the old feature and set the owner for the new feature.

Update conflicts appear in the My Tasks view if you own the feature.

Click on the Resolve button to launch the Changeset Dialog and resolve any conflicts.

In Summary

This blog has described how to reschedule tasks and features and how developers can switch their changes to the new version.

• Moving tasks and features in the Projects view is trivial.
• If a developer is working on a task in a workspace then PureCM will switch the workspace to the new version.
• If a developer has submitt ed changes to the feature then these changes will be merged to the new feature stream.
• Moving a feature may create update conflicts which can be resolved within the My Tasks view.

Lee has started to talk about merging in his last blog, as he showed how to apply a hotfix to the current development version. I’ll take on his topic to talk about one of PureCM’s most powerful features: automated merging with ‘Merge Rules’.

Where does merging happen?

PureCM is a client/server based solution, so the all project data is stored in a safe repository. As a developer, you work in a so called ‘workspace’, a local copy of any project held in the repository. This solutions has the benefit of supporting both concurrent and offline development.

The following diagram shows you that there are basically two cases when you might merge:

1. When updating your workspace based on a version or feature to get your colleagues’ changes.
2. Directly between branches on the server. Examples for the latter are merging between different versions or development stages of a project, e.g. from development to test.

Updating a workspace is always ‘on demand’ to let the developer decide when to get the changes. Merging on the server can be performed by a user with the necessary permissions, or automatically using merge rules. 

It’s worth noting here that PureCM always merges tasks, i.e. a submitted changeset and not individual file changes. This makes merging extremely transparent, as you’re able to track that you just merged ‘bugfix a’ or ‘feature b’.

Why you want to automate merging with ‘merge rules’

Merge rules are a very powerful feature that allows you two things:

1. Automatically track changes submitted to one branch (source) that are not present in another (destination). For example, the owner of a development version gets notified about new bug fixes made to a maintenance version
2. Automatically merge changes submitted to one branch (source) that are not present in a second (destination).

This means that a development manager can basically work with two levels of automation. Level 1 highlights pending merges and lets him preview and confirm (or exclude) the merges. Level 2 merges changes straight away and only notifies in case of a merge conflict that has to be resolved.

This results in reduced overhead when managing parallel development and avoids human error and regression bugs. Merge rules are created automatically in the following cases:

1. Automatic tracking is enabled from parent to child versions, e.g. from ‘Version 1’ to ‘Version 2’ as seen in the last blog
2. Automatic merging is enabled into features to keep the feature branch automatically up to date and minimise overhead

A development manager can get an overview of all existing merge rules in the ‘Merging’ view. Here, all merge rules between active versions and features are listed. To keep the view tidy and avoid unplanned merging, merge rules are automatically removed as soon as the version or feature is completed.

Customising merge rules

The Merging view is also the place where development managers can change merge rules as needs dictate. They can change existing merge rules from automated tracking to automated merging and vice versa, or create new merge rules from the menu of the ‘Merge Rule’ folder:

The one condition to respect when creating new merge rules is that the source and destination branch must be part of the same branching hierarchy. In other words, they must have a common ancestor, which is typically the case within a project.

Performing one-off merges

Merge rules are the perfect solution if two branches have a longer lived relationship. However, sometimes you just want to merge a single change without the need to create a merge rule. This is very simple in PureCM and can be done by selecting a completed task and select ‘Merge Change To’.

This will bring up a dialogue where you can select the destination. That’s it. 

Merge tracking

Thanks to its stream-based branching, PureCM can track the merge history of any task throughout the full project hierarchy. Simply access the task properties and select the history tab to see to which versions and features it has been applied to.

We’ve actually finalised another nice feature for our next release in July that allows users to list all releases a task is present. If you’ve ever wondered whether a bugfix has gone into this or that release, this new feature will be an invaluable time saver!

Summary

This blog has covered how development managers can take advantage of PureCM Professional’s merging capabilities to automate parallel development.

• Merge rules either track or merge changes automatically
• Existing merge rules can be customised and new merge rules created
• Notifications are automatically made to the owner of the destination version
• Merge rules are automatically removed once a version or feature is completed

Stay with us and learn how you can reschedule tasks and features as part of an agile planning process – even if coding has already started!

We’ve now covered the development journey from setting up a project hierarchy and assigning features and tasks to completing work. It’s time to have a look at how you can keep track of what’s happened. PureCM offers several ways to visualise project status, which I’ll present below.

What information do you need?

True, there are countless reports, diagrams and options when looking at reporting. But if I try to reduce to the max, as a development or project manager you’ll quite likely want to get answers to the following questions:

• What has been completed in this version (or iteration)?
• Which tasks are still open?
• Who is working on what?

Note that I’m usually referring to features and task when asking these questions. I want to see which features have been implemented, not which lines of code have been changed. The latter is very important, too, and will be covered in the next blog.

What has been completed in this version?

Getting the current project status

With PureCM, you can easily get that information in the Projects view. Select the project or version you want to look at and simply set the filter to ‘Completed tasks and features’. This will give you a list of all work items that have been completed. 

From there you can immediately drill down to more detailed information, e.g. show all tasks of a feature or all files that were changed/added/deleted as part of the change. Or you can check into which other versions or features a specific change has been merged into.

If you also want to see all release snapshots that were taken, click on ‘Show submitted tasks and releases’. This will open a chronological view of how the changes were applied to the server. 

Progress over time: the project burndown

The above has given you a quick update on the current status, but you don’t see how you’ve progressed during, say, the last iteration. Of course, you can save the task lists at multiple times to get a burndown report, but this is definitely too manual a task. So let’s change to the ‘Reporting’ view, where we can create report templates. 

With the next PureCM release in July you’ll get three new task-based reports with the Professional edition: The burndown, burndown with priority and the developer status report. All three allow you to define a template that dynamically generates a html report that you can customise, print and/or export as CSV or XML.

Besides getting a good feeling for velocity (“how many tasks do I typically complete in a certain period of time?”), an increase in total tasks also shows you whether you’ve suffered from scope creep. Reporting is an area we’ll be working on further, so feel free to share your needs with us!

Which tasks are still open?

Now that we know what has been completed, we can check on what is still open. Again, we can start from the Projects view and set the filter to ‘Open tasks and features’. From there we can filter on a specific task status or priority to get a better idea of where we are just now.

As before, you can also switch to the Reports view to see how the number of open tasks has evolved over time to estimate how likely it is that you finish all open tasks for the current iteration or version. This time, I've exported the CSV and created a standard chart in no time.

Of course, not all tasks have the same importance. Thus you can also get a burndown per priority to check whether at least your high priority items can be completed as planned. ;)

Who’s working on what?

Finally, you might wonder which of your team members might have some free resources... To do so, you can again use the Projects view and filter on a specific user name or run the developer status report. The project view might be more useful if you’re about to assign work, as you can do that from the same view. On the other hand, the report is easier to show or print for a progress meeting with your team, as you can list all developers at once.

Summary

I’ve covered three basic reports that most probably all project managers need to answer. More specifically, I’ve covered the following topics:

• Current project status from the Projects view: Completed or open tasks that allow fully dynamic drill down from feature to code line.
• Burndown report from the Projects view: History of completed and open tasks for a given period of time, typically based for estimation
• Report templates can be customised, printed and exported as CSV/XML

With this, you should be armed for any progress meeting. Tim will move a step forward on the development lifecycle and explain how you can create release snapshots, retrieve them and visualise the file and folder differences.

In the last blog Tim described how a developer works with tasks to complete small units of work. I will follow on from this to discuss how a developer works with larger pieces of work.

My Features

We have already introduced the concept of a feature and described when a manager should create a feature as opposed to a task. So lets assume a manager has already assigned a feature to you.

After a feature has been assigned to you it will appear in the ‘Workspaces’ view under ‘My Features’.

From here you can:

• Open a workspace for the feature. This will allow you select an existing workspace or create a new workspace.
• Show the file differences between the feature and the version.
• Complete the feature by merging all the changes back into the version.

Feature Workspaces

To start working on the feature press Open and select an existing workspace or create a new workspace. If you have already created a workspace for a feature which you have completed then you should select this workspace. This will switch the workspace from the old feature to the new feature. Switching a workspace is a lot quicker than creating a new workspace.

After opening the workspace you can start working on the files the same as if you were working against the version directly. You can use any of the PureCM clients or one of our IDE plugins such as Visual Studio or Eclipse.

The difference between working on a feature, rather than working on the version directly, is that submitted changes are only applied to the feature. So you can checkpoint your work, submitting unfinished changes, without breaking everybody else’s workspace.

Completing the Feature

When you have submitted all the changes required for a feature it is time to complete the feature and merge the changes back into the version. In the Workspaces view press Complete.

This will open the Changeset Dialog showing all the changes for this feature.

Press the Submit button to apply these changes to the version. All the feature changes will be merged back into the version as one changeset.

Features & Tasks

If you are using features and tasks then you start working by selecting Start on the task in the My Tasks view, as described in Tim’s blog. Whether the task is part of a feature or version makes no difference when working with tasks; PureCM will automatically populate your workspace with the correct files and folders.

When all the tasks within a feature have been completed, the feature will appear under ‘Pending Features’ in the My Tasks view. From here you can Complete the feature to merge it back into the version. The feature will only appear under ‘Pending Features’ if the feature is assigned to you.

In Summary

• You can create a new workspace or switch an existing workspace to start working on the feature.
• You can checkpoint your code within a feature workspace without breaking everybody else’s workspace.
• After submitting all the changes to the feature you complete the feature by merging all the changes back into the version as a single changeset.
• When working with tasks, it makes no difference whether you are working on a feature task or a version task.

The next blog will describe how you can use features to perform code reviews.

In this part of the SDC series we are focusing on a developers day to day life. Last time Lee looked at developer workspaces, now we are going to look at how tasks interact with and manage those workspaces.

My Tasks

We already introduced the concept of a task in my last blog looking from a managers point of view. To a developer a task represents  a small chunk of work that has been assigned to them to complete. These can be easily viewed from the 'My Tasks' area.

As you can see the tasks in this view are broken down into three sections; 'Working', 'Assigned' and 'Group'. These divide the tasks between those that have been linked to a workspace and those which have not. Each section is sorted by priority to help you complete the most important tasks first.

To link a task to a workspace select start button. This will launch a dialog to let you select your workspace. By default it will highlight a workspace connected to the same version as the task. You can always chose to switch an old workspace by selecting it. If no workspaces exist it will launch the new workspace dialog and automatically select the correct version.

Group Assigned Tasks

These are tasks that have been assigned to multiple users using a group. This does not mean that they all work on the same task together, instead it provides a good way for managers to put tasks into a pool for a team to complete (This can be great for end of release bug fixes). As soon as a developer starts work on a task he removes it from the pool and assigns it to himself.

What does Complete do?

For both assigned and group tasks you get the option to complete it. This is designed for when the task is completed without any changes to the server. These cases can include testing tasks or simply tasks that have been completed already.

Working Offline

If you ever need to work while being disconnected from the PureCM server you will be happy to know that tasks assigned to you are stored locally for you to continue working.

Inside your workspace

Each task linked to a workspace acts as a changeset. You can work on multiple tasks at once as different changesets by simply starting work on multiple tasks.

Sometimes you may have no choice but to implement two tasks as one changeset. In this case PureCM allows you to submit the changeset with both tasks assigned to it. From the submit dialog you need to switch to the 'Tasks' tab and select all of the tasks you intend to submit.

When you know which workspace you are working in and want to select the next task without changing your view, select the 'Current Tasks' node and choose the 'Work on Task' item. This provides you with a way to select the task you want to work on or even create a new task inside the correct version.

In Summary

• You can complete a task without submitting a change from the My Tasks view.
• Tasks can be assigned to a group to allow any developer from the team to work on it.
• Tasks assigned to you are stored for offline work.
• You can link multiple tasks to a changeset by selecting them in the submit dialog.
• You can create new tasks from inside your workspace using the work on task dialog.

The next blog will look at larger work items that are too big to handle with a single task.

Up to now, the blogs have focused on a manager's point of view of using PureCM's project features. This blog will focus on a developer's perspective.

Where developers work ..

The workspace is (always) where developers work. This is a local copy of a version, feature or release where the developer can perform day to day operations using features such as Checkout or Submit.

By having a local copy of files and folders the developer can work independently of other developers, and choose when to either integrate others' changes, or when to submit their changes.

A developer can have multiple workspaces at any time and can also switch a workspace to point to a different Version. 

Using Workspaces

As an example of using workspaces I will explain how I currently work ..

I have multiple workspaces, of which two I actively use on a day to day basis. One is based on a feature that I am implementing for the next major release of PureCM (2010-1-r2). The other is for any bug fixes that I am tasked with for the current release (2010-1). As you have seen in the previous blog, versions and features get their own branch in PureCM. This means I currently keep an active workspace for each different PureCM release I'm working on and switch workspaces between features.

The feature has been broken down into several tasks, which on their own involve small amounts of work - roughly no more than a day for each. 

By navigating to the 'My Tasks' tab I can select a task to begin work on, by clicking 'Start'..

Here I can choose the workspace where to carry out the work. In the workspace, I checkout the files relevant for the current task, make the changes, and submit the work. The work is submitted via a changeset. The changeset shows the files involved (edits, adds of new files, and any deleted files). The task is also shown as a tab on the changeset. The task description is automatically added as the changeset description - this can be amended if required.

Usually, before submitting changes, I would make sure the workspace is up to date (with others' changes). This is done with the 'Update to Latest' operation on a workspace node, or the 'Update' button found in the 'Workspaces' page to the right of the relevant workspace (See image below). It is possible to have PureCM automatically update a workspace immediately before a submit. This is one of the options found in the Option dialog found in the 'Tools' menu..

Once submitted, the changes are uploaded to the feature, the task is completed and I can move onto the next task. 

This process is repeated until all tasks in the feature are completed. At this point the feature can be completed. Depending on how the features are set up, this could involve code review before the changes are finally merged into the parent Version.(There will be a blog written soon covering this topic). 

Workspace Switching

Moving on to another feature involves simply selecting a task from the 'My Tasks' list and, when the same workspace is selected, PureCM automatically switches the workspace to point to the new feature that the task belongs to.

As for the other (2010-1) workspace I have, changes are made and submitted directly to the Version. If changes are required on a different version, then the 'Switch Workspace' option in the workspace/Advanced menu allows a different version to be chosen. The workspace is then updated with the relevant files. The 'Workspaces' tab also alows you to 'switch' a workspace..

In Summary

• Workspaces are local copies of a version, feature or release
•  Changesets are used to submit changes to the server 
• 'Update to latest' keeps the workspace up to date 
• Workspaces can be switched to different versions (automatically or manually)

We briefly touched on the use of tasks in this blog. The next blog will focus specifically on tasks, and working on small work items.

SDC part 2 looked at managing your project structure using versions and releases. This blog is an introduction to creating, organising and scheduling work between your releases.

Specify your Work

We need a way of recording work that needs to be done. Using PureCM projects this is done using both Tasks and Features.

Tasks

A task is the basic building block of project workflow. Ideally it should be a small self contained item that will be submitted as one changeset. Large pieces of work should be broken down into the smallest chunks possible. Code changes you make will be recorded against a task, so you can track its full history from creation to completion.

Features

A feature is a piece of work that is too big for a single submit. We have all been in situations where we are sitting with a couple of days changes in our workspaces that we don't want to submit because they are incomplete and may break others' builds. This is obviously bad practice as you often have no backups or checkpoints and it becomes increasingly hard to manage. A feature gives you a branch where you can submit your changes and then choose when they are merged into the version. This has the added advantage that the version remains release ready at all times.

A good way of working with features is to break down the work further into tasks inside the feature. This has the advantage of helping developers keep track of the work to be done and helps managers keep track of the progress of the feature. It also is an easy way to assign different parts of the feature to different developers.

Scheduling your Work

Now you have some tasks and features you need to decide in which version they will be completed. Tasks and features can be created directly into a version. This can be really useful for bugs when you know which version they need to be fixed in, but future development ideas can be harder to place into a version.

Project Backlog

The project backlog is a place where you can create and store tasks and features that you have not yet scheduled to a version. It can be good practice to have developers raise tasks in the backlog for a manager to schedule into the correct version. Scheduling tasks and features is particularly easy as it can be done by drag & drop.

Organising your Work in Folders

Keeping your tasks organised is an important job, and it can be very useful to group together tasks and features which share a close relationship. This is done through the use of Folders. Folders can be made in both versions and the project backlog.

Getting the work done

Now we have our version full of the tasks we want to complete, so we can assign them to the relevant developers. By giving each task a priority we can also define a work flow for the developer as their highest priority tasks will appear at the top of their to-do list. Remember you can always (re-)assign or change the priority of multiple items at once from the Projects view.

Summary

In this blog you have learnt:

• The difference between tasks and features and when to use them.
• How to schedule your tasks against the correct version.
• What the project backlog is and how to get the most out of it.
• How to organise your tasks using folders.
• How to assign tasks to developers to get the work completed.

The next blog 'SDC Part 4: Branching Patterns' will give you a look at what creating versions/features/releases does behind the scenes and how you can best set up your project to make use of this.

This blog is an introduction to creating projects, versions and releases using PureCM 2010.

Creating a Project

The first thing you need to do is create a PureCM project. A project is a self-contained set of files. You can share files between projects using components, but this is too big a topic to discuss here.

Launch the PureCM GUI and go to the Projects View. Right-click the ‘Projects’ tree item and select ‘New Project’. Here you can specify a name and description for your project

Creating Versions

A project will contain one or more versions. How many versions you create and what you call them will depend on how you develop your project.

The first question you need to ask is: Do I need to develop different versions of the project at the same time? If the answer is no then you only need a single version – probably called something like ‘Development’ or ‘Main’. If the answer is yes then you need to create a PureCM version for each version you will be working on.

For example, suppose the project is a website which is constantly being updated and the latest files are uploaded to the web server at various points. The project needs to only have one version.

Or suppose the project is an application which is released as incremental versions, but each version contains the latest code. The project needs to only have one version. You could create a PureCM version for each version of the application – but it is more work for you.

Now suppose the project is an application which is released as incremental versions, but each version does not contain the latest code. So for example you release ‘Release 1.1’ and start developing ‘Version 2’. You then find a bug in ‘Version 1’ so you want to release ‘Release 1.2’. But you do not want ‘Release 1.2’ to contain the ‘Version 2’ features (Features 2 & 3). The project needs to have a version for ‘Version 1’ and a version for ‘Version 2’.

To create the first version right-click the project and select ‘New Version’. Here you specify a name for the version. The initial version will always be created from scratch. To create a version from another version right-click the first version and select ‘Create Version From’. You will notice that now the new version is based on the version you selected.

It is very important that any new versions are created from the correct version, e.g. ‘Version 2’ is created from ‘Version 1’. This is so that ‘Version 2’ will initially contain the same files as ‘Version 1’.

Staging or Promotion Models

Another reason to create versions is to support staging. The most common example of this is where you have a ‘Development Environment’ where your developers submit code and an ‘Integration Environment’ where your testers test the code. What you want to avoid is having a code freeze – stopping your developers from submitting changes until the testers have tested the code.

To achieve this simply create the ‘Development’ version as described above. From this you can create the ‘Integration’ version. All the developers will work on the ‘Development’ version and at various points a manager can merge the changes into the ‘Integration’ version.

To support staging and parallel development you need to create the staging version from each development version. So you will initially create the ‘Version 1 Development’ version and from this you will create the ‘Version 1 Integration’ version. When you are ready to start developing Version 2 you will create the ‘Version 2 Development’ version from the ‘Version 1 Development’ version. You will then create the ‘Version 2 Integration’ version from the ‘Version 2 Development’ version.

Of course you are not restricted to one staging environment. For example, you might create the ‘Production’ version based on the ‘Integration’ version.

Iterations or Sprints

A common question is how to handle iterations or sprints and whether you should create versions for them. The same rules apply here as with parallel development. If you are working on 2 or more iterations/sprints in parallel then they should be separate versions. If the development is linear then you only need one version.

Creating a Release

A release is a snapshot of the version at the time the release was created. By default, the files within the release will not change. So a release is used by the build managers to build the release and by the developers to test for a bug within the release code.

To create a release, right-click the version you want to create a release from and select ‘New Release’.

To view the releases of a version, right-click the version and select ‘Show Submitted Tasks and Releases’. This will give you a list of the changes submitted against this version and where the releases were created.

Summary

In this blog you have learnt:

• How to create a project.
• If you work in parallel development then you need to create a PureCM version for each new version of the project.
• If you work with staging environments then you need to create a PureCM version for each stage.
• When creating a version it is very important to create it from the correct version.
• How to create a release and view all the releases for a version.

The next blog ‘SDC Part 3: Defining a Work Item’ will describe how to create tasks and features within a version and assign them to a developer.