Name of the blog

Short description of the blog

New Blog Series: Agile Version Control

A few months ago we've run our first blog series, publishing about a dozen blogs on how common software challenges can be tackled effectively. The SDC series was born. We've had some great conversations with readers and customers as result of that blog series, so I'm glad to announce the next series that will start soon:

Agile Version Control


Hmm. Agile in 2011? Ten years after the agile manifesto was published? Of course! These 10 years have brought many rich experiences working with agile and other methodologies in software development. We still get numerous rich and insightful discussions with our customers about what could be done better. And at the same time, we're also confronted with "how to" questions from teams getting started with agile: How to make version control or software configuration management (SCM) agile?

It's seems to be a small part of the development process only, and yet getting it right is a key success factor to any agile initiative. So join our upcoming agile version control series to get in touch with best practices and let me know about your thoughts.

 

Modular Software and Version Control

 

There are many issues to consider when deciding how to structure your software from an architectural point of view. Chances are that you’ve already split up your code into several modules or components to separate the various routines.

However, deciding about the best software design isn’t the purpose of this blog. At PureCM, we like to look at software from a version control point of view. So let’s agree for the purpose of this blog that a component is a set of files and folders that are versioned together. This also means we’re looking at code components, and at referencing compiled DLLs or the like.

To modularise or not to modularise…

Remember, we’re looking at this question from a version control point of view. So basically there are two options: consider project as one module, or having many modules that are developed individually.

The advantage of having one module for the whole project is obvious. The project gets always built and versioned as a whole, while release snapshots are also taken from version branches as a whole. Also, creating a workspace for a version or feature would always populate the developer workspace with the full content:

Simple. So why would we want to have separate modules?

One of the main reasons is that you might want to reuse certain modules or components for other projects, that they might suddenly get their dedicated developer (team) and individual release cycles. As a consequence, these components need their own container in order to version them separately from the projects they are linked to.

Shared components – an example

Let’s assume you’re using your icon component across multiple projects, with only a specific group working on them – I’ll call them ‘magic designers’. They are the only ones working on these files, so don’t really need to get the other project content to make their changes.

In such a case, you can give them their own version branch in PureCM, which only contains the ‘icons’ components files and folders. Any of your projects using that component could then link to that component version.

So now your developers can either create a workspace for the relevant project version/feature, or the shared component only.

 

Sharing component releases or all changes immediately?

Using shared components in PureCM also gives you another option. You can choose whether you want to share a static component release or dynamic component version.

The obvious advantage of sharing component releases is that changes made against the component version aren’t shared until t ested and ‘released’ as a release snapshot. A development manager would then simply update the component link to the latest component release to update his project. Of course, this also assures that you can link your projects to different component versions as needs dictate.

O n the other hand, there are cases when you’d want to immediately reflect changes made to a component across all linked location. Linking to the component version allows you to do so. Of course, even with this solution you can have your ‘magic designers’ group work on multiple component versions without problems.

Summary

Which of the discussed option you choose is down to your needs; the following t able summarises the available options in PureCM:

 

Only share stable component updates

Share component updates immediately

Support one component version only

Link to relevant component release

Link to component version

Support multiple component versions

Link to component release of the relevant version

Link to relevant component version


However, as a development manager you can be sure that PureCM tracks all your changes across all linked locations:  any changes made to the component, when a component was linked to which project, at what point the link was updated to a newer component release etc.

If you work with PureCM Professional and use tasks, you will get even more information. PureCM will show all tasks originally completed against a component in the history view of any linked location - and the other way around. Not bad to facilitate release note creation (and have a full, repository-wide task history)!

If you want to learn more about working with shared components, there’s also a white paper available. It covers the above and component setup in more detail. Just download it from here:

http://www.purecm.com/download_file.php?type=white_paper&download_id=7

 

The advantages of task-driven development

 

Over the last few years, we’ve seen a large number of development teams moving away from file-based version control tools. This is no surprise, as new tools on the market started to support the concept of changesets and atomic commits.

Why grouping changes makes sense

So instead of checking in every single file, developers were now able to group their changes in changesets. This gives teams a much better project history, as each changeset reflects a task. Also, changesets are applied to the repository database atomically, i.e. completely or not at all, thus protecting database integrity.

Distributed version control systems and, of course, PureCM also allow developers to create, checkpoint or rollback changesets without needing a connection to a central server. But task-driven development doesn’t stop there. You’d want to link your changeset to its original change request or defect in your issue tracking tool.

Easy: add the issue reference as a comment, or link it to your changeset using a 3rd party plugin. But what if you’re working on parallel versions, where changesets get merged across project branches? Do you still know to what versions your change has been applied to? Or how do you track your changes when implementing code reuse across projects?

How to keep track when working with parallel versions?

Typically, only your original changeset will be linked to the original issue, but it quickly becomes a manual and cumbersome process to find out into which releases, say, a particular bug fix has finally made it. This is where PureCM’s end-to-end focus on task-driven development comes in, providing a full picture with on a simple mouse click.

Watch the short 3 minute demo to learn how you can get full transparency between project branches and even when sharing components across multiple projects. Ah yes, here’s the link: http://www.purecm.com/file_downloader.php?type=video&download_id=8

I hope you like it!


 

SDC, Part 12: Parallel Development with Merge Rules

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!


SDC, Part 9: Project Status Reporting

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.


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.

 

New Blog Series: Solving Development Challenges (SDC)

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.

 

Comment on our product roadmap!

Looking into 2010 from a PureCM point of view

Exciting times are ahead with the PureCM 2010-1 beta now available for download and the full release coming closer. As this release will mark a very substantial step forward regarding PureCM's feature set, it looks like this is a great moment to share our product roadmap with you.

Please feel free to comment; regardless of whether you want to praise or criticise! 

Feature

Target release

 

Release planning, task tracking

  • Agile release planning for multiple projects using releases and iterations
  • Support product backlogs and drag & drop scheduling
  • Link configuration management to release planning
  • Support real-time status updates
  • Support visual reporting with burndown charts
  • Support attachments and comments for tasks
  • Support for multiple task types

 

 

2010-1

 

2010-1

2010-1

2010-1

2010-2

2010-2

2010-2

Configuration management

  • Visually show release a change has been introduced, e.g. a change or bug fix
  • Improve resolve dialogue for easier copy & paste

 

 

2010-1

 

2010-2

Integrations

  • Support working on tasks in Visual Studio
  • Support working on tasks in Eclipse
  • Support changeset references to Gemini issues
  • Add full integration to Gemini to provide a web front end and helpdesk integration

 

 

2010-1

2010-2

2010-1

2010-2

DB Backend

  • Support SQLite as embedded and cross-platform database backend
  • Support SQL Server databases

 

 

2010-1

2010-1x

 

 

Gemini issue integration available now

We have just released the latest plugin for PureCM, which links changesets to issues in the Gemini issue tracking tool. Why Gemini? We've had various customers asking how they could best use PureCM with a web front end for their helpdesk team. As we've been focusing on developing a tight release planning/configuration management integration with the upcoming 2010-1 release, reaching to teams outside core development is currently better supported with 3rd party solutions such as Gemini. This tool is particularly well suited to integrate with PureCM given its simple yet flexible user interface. 

How does it work?

The main imperative when developing the Gemini bridge has been to keep it simple. Linking PureCM changesets to Gemini issues can be done simply by adding a 'GEM' reference number to the changeset description - that's it. There are some screenshots in our knowledge base that show you how this will look. What might be more important is actually the way the bridge is published: as open source. Yes, that's right. It's the first time we do so and we hope that you'll embrace this approach.

Why is the plugin open source?

This is a very simple integration, which requires minimal setup and virtually no training for developers. On the upside, this gives you a quick and easy integration with a web frontend to add powerful helpdesk functionality to PureCM. On the downside, the plugin doesn't include sophisticated checks, e.g. to make sure you avoid typos when adding the Gemini issue number. By publishing the solution open source, you can decide whether this fits your bill or whether you'd like to add some tweaks.

Furthermore, keeping the integration so simple also makes it very easy to use it with other issue tracking tools. You can get the plugin and customise it to work with your existing solution, getting a head start with the now available and fully commented Gemini bridge.

>> Download the Gemini bridge here

 

So where do we go from here?

As you might have guessed, this is but a first step. This bridge is great for a no-frills integration with Gemini, especially when you simply want to keep track of what has been submitted against a specific issue. However, with the new release planning functionality in PureCM 2010-1, we'll be able to look at a much tighter integration with Gemini. Think scheduling in Gemini that is reflected in PureCM. Think getting real-time updates on project status regardless of the tool you're currently working in. Having development and non-development teams collaborate along the development lifecycle based on the same up to date information, but using the frontend (or tool) that is most natural to them.

Make sure to revisit this blog - we'll keep you up to date on progress!

 

The PureCM GUI Views: Part 2

Well, this time the title might be slightly misleading. It should rather say something like ‘The PureCM GUI Views: Part 2 – kind of...’, as I’ll not talk about the PureCM GUI client itself, but about the GUI most developers face on a daily, well most probably even on a constant, basis: their IDE.

Whether it’s Visual Studio, Eclipse or any other solution, flicking between tools isn’t just a hassle, it might even lead to (manual) workarounds that potentially affect product quality. With today’s multi-screen infrastructure and powerful integrations, arranging the information you need has become much more flexible and comfortable. We were obviously delighted to see Microsoft adding a proper API to Visual Studio 2005+, allowing us to provide an enhanced plugin, e.g. to suppor custom panes that any developer can arrange the way he wants.

So something that starts off as being better ergonomically might in fact have implications for your productivity and quality of work. Being able to see your current checkouts and group them into one or more changesets clearly helps to structure your work without the need to use ALT+TAB all the time. We’re not alone with this view, as Adrian Bridgwater at ZDNet UK has also picked up on the topic in his app dev blog. And there are also Eclipse enhancements scheduled for PureCM 2010-1.

By the way, the PureCM 2009-2c release that has become available last week includes some enhancements to make the annotated file history work with the Visual Studio enhanced plugin. This might prove a welcome feature, especially when chasing down bugs in your projects. Know who’s last changed a line, when and why.

You can grab the release from our download section; and if you’re not familiar with our these features yet, why not have a look at our enhanced VS plugin online demo?