Name of the blog

Short description of the blog

SDC, Part 7: Working on a Larger Work Item: Features

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.


SDC, Part 4: Branching patterns

 

So far, we’ve covered the new planning functionality of PureCM Professional. You’ve seen how to define project and versions and how to schedule and assign work items using features and tasks.

 

Is this series going to be all about release planning?

So all about project management and nothing on software configuration management (SCM), the traditional core of PureCM. Clearly not! PureCM 2010 fully integrates release planning and configuration management, offering important benefits to the user:

  • In smaller companies, planning and configuration management is often looked after by the same person. In this case, using PureCM 2010 results in much simpler administration and less overhead
  • If planning and CM is done by different persons, PureCM 2010 allows for an easier collaboration and real-time project status updates for both sides
  • Developers only need one tool to manage their work items and complete them, which again reduces overhead

 

How does planning relate to configuration management?

First, a quick refresher about glossary. PureCM uses the concept of stream-based branching. This allows changes being automatically inherited between streams, making streams something like next generation branches. However, to facilitate our discussion, I’ll simply use the word ‘branch’ in this blog.

To understand the link between planning and CM, let me put the two sides next to each other. When planning your releases by creating versions and scheduling tasks using the Projects view, PureCM automatically prepares a branch for every new version. This is visualised in the diagram below; on the left is what you create using the Projects view, and on the right is what PureCM does for you in the background.

The word ‘prepare’ is important here, as the branch only gets created when the first user starts work on it, i.e. the first workspace is based on this version. So when the first task is worked on, the branch is created from the head revision at that point in time. The advantage here is that you can already start scheduling for the next version without separate branches, so no merging is needed until work has started on both versions. Once work has started, you’re automatically able to work in parallel.

What’s important is that PureCM automatically tracks and notifies the version owner(s) about changes present in one version but not a related one. Which notifications owners receive can be customised by adding or modifying merge rules between versions. You can imagine that notifying owners about pending merges and tracking them after completion reduces human error and facilitates parallel development enormously. I’ll not go into details here, as merge rules will be covered separately.

Of course, you can customise branch creation as long as work hasn’t started on a version. Say you want to link a new version to the same branch as a previous version. This is useful if you only want to separate versions for scheduling, but submit changes against the same branch, the latter becoming your development mainline. This would look as follows:

So a project and configuration manger can sit together when planning a release and collaboratively decide on the best approach. Note that you can also hide versions from the projects view once they don’t need to be supported anymore. This keeps the Projects view tidy and makes it easy to navigate when scheduling and tracking progress.

 

...and how do features work?

When scheduling a feature in PureCM, the tool also prepares a branch, just as with versions. However, features are typically used in a different way than versions: versions tend to be longer lived, and you only merge selected changes between versions. On the other hand, features tend to be short-lived and will get fully integrated back into their parent version. This is shown on the next image (release snapshots are omitted for simplicity).

By listing incomplete features as children of the version they’re scheduled against, managers get an instant feedback about work in progress, while developers can easily define tasks for a feature to split up their work. Any feature in progress won’t be included when building the version. To get an overview of all completed features, tasks and release snapshots of a specific version, right-click on the version and select ‘Show Submitted Tasks and Releases’.

The big advantage working with PureCM features comes from the fact that it uses stream-based branching. Therefore, a feature automatically inherits all changes that are submitted against its parent version. This is explained in one of Stephen's earlier blogs. You can turn this off again by changing the merge rules, but we've never seen anybody doing this after realising the benefits... Note that working with features also allows for powerful code reviews before integrating the feature. 

We'll revisit features from a developer perspective in a later blog of this SDC series to discuss how they can best work with features.

 

Summary

This blog has focused on the benefits you get by working with an integrated release planning and CM solution. Parallel maintenance and development can be automated and thus managed with little overhead.

Let’s revisit the main issues I covered in this blog:

  • Project and development managers can collaborate in the ‘Projects’ view when planning their releases and customising their configuration management
  • Versions prepare a branch as a default and support automated notifications about pending merges
  • Features prepare a branch as a default and are automatically kept up to date for easy integration once completed
  • Configuration managers can customise and combine the use of versions and features, e.g. using multiple versions to assure maintenance on more than one release

So far, this blog series has focused on the manager’s perspective when setting up the basics of the development lifecycle. Starting with the next blog, we’ll change hats and discuss how developers can benefit when working with tasks and features.

 

SDC, Part 3: Defining a work item hierarchy

 

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.