Name of the blog

Short description of the blog

Jenkins and Hudson Plugins coming soon in 2013/2

With the 2013/2 release now less than a month away we wanted to outline some of the major new features.

One of the biggest features of the 2013/2 release is the plugin for Jenkins and Hudson. In case you did not know Jenkins/Hudson is an open source Continuous Integration tool similar to CruiseControl. Hudson was the original application but this was forked in 2010 by unhappy open source developers to create Jenkins.

 

PureCM already has plugins for CruiseControl.NET and FinalBuilder - so why do we want another CI plugin?

 

Firstly Jenkins/Hudson has possibly become the most widely used continuous integration tool. This is down to it's active open source community, ease of installation, ease of use and number of plugins. So if you are looking to choose a new CI tool - CruiseControl, Jenkins and FinalBuilder are 3 of the best available.

Secondly we already have customers who are using Jenkins and Hudson. So if you are already using Jenkins/Hudson then it will be simple to install the PureCM plugin and get going with the PureCM streams.

The final benefit is that Jenkins/Hudson is cross-platform and is more commonly run on a linux server. This is not the case for FinalBuilder or CruiseControl.NET.

 

What does the plugin do?

 

Similar to the CruiseControl plugin the plugin allows Jenkins/Hudson to check if any submits have been performed against a stream and update the workspace to get the latest code. Jenkins/Hudson goes a bit further than CruiseControl in that it lets you browse the workspace files. It also gives you more details about the change - like what files have been added, edited and deleted.

 

When will the plugins be available?

 

Unfortunately the plugin required some changes to the pcm command line so they will not be available until the release of 2013/2 in October 2013. If you want to get a beta version of 2013/2 along with the plugin please email support@purecm.com and we will send you the details.

Ignoring Files with pcmignore Files


One of the key features of the 2012/2 PureCM release is the introduction of pcmignore files. I want to explain what they are and how they can make life easier for you. If you are familiar with gitignore files then we have some good news - they are identical.

 

The Problem – The Ignore File Paths Policy

 

More often than not there are files in a workspace which you do not want to control. These might include user option files or build files. The previous way of handling this in PureCM was to update the 'Ignore File Paths' policy. So the policy might include the pattern '*.obj' to ensure object files are not added to PureCM.

This policy will carry on working the same as before so if this is working well for you there is no need to change anything. But you may not like this way of working for one or more of these reasons:

  • It is difficult to maintain the 'Ignore File Paths' policy, especially if you have different patterns for different streams. If you decide you want to add a new pattern you have to update this policy in each policyset.
  • Users need to access the Administration view to update the policy. It is unreasonable to expect all developer to become familiar with PureCM policies.
  • Users need to be a Policy Administrator to update the policy. It is very common that an Administrator would not want all users to be able to update all policies.
  • You cannot specify complicated rules. For example you could not say "Exclude all files in a 'Debug' directory except the files in '/src/Debug'".

For these reasons many users have stopped using the 'Ignore File Paths' policy preferring to manually remember which files to not add. But this approach is not recommended for the following reasons:

  • New developers might not know which files to exclude.
  • You are less likely to run the Check Consistency Wizard which makes it more likely that you will forget to add a new file.
  • You cannot use the 'Monitor the workspace for file changes' feature which will automatically add files to your workspace when you create them.

 

Better in Every Way - pcmignore Files

 

Using pcmignore files will resolves all these issues. A pcmignore file specifies any number of exclude and include patterns. This is similar to the 'Ignore File Paths' patterns but you can specify include patterns the same as exclude.

When you put the pcmignore file in a folder, the include and exclude rules are applied to that folder and any subfolders. So it is easy to specify complex rules like "Exclude all files in a 'Debug' directory except the files in '/src/Debug'". The root pcmignore file will have a rule to exclude all files in a Debug directory. The 'src' directory has a pcmignore file with a rule to include the Debug directory.

The pcmignore files are submitted to PureCM the same as any other file. Other developers start using the new pcmignore rules after they update their workspace. Developers can add new rules or update existing rules easily by checking out the pcmignore file, updating it and submitting the change.

 

Switching Over

 

Hopefully you are eager to start using the new pcmignore files. To get going you need to add a file with the name '.pcmignore' at the root of your workspace. This file contains all the exclude and include rules which apply to all folders in the workspace. You can download a good starting point from here.

Note: If you create a new stream from scratch then the default .pcmignore file is added automatically.

There are many example gitignore files which you can download here. pcmignore files and gitignore files are identical, you can even call the file .gitignore.

After adding the root pcmignore file you can go through each entry in the 'Ignore File Paths' and add any useful patterns to the pcmignore file.

The best approach is then to clear your 'Ignore File Paths' policy and run check consistency on a workspace where everything has been built. Look at the files which PureCM wants to add and add them to the pcmignore file. Keep doing this until running check consistency finds no new files.

AVC 2: PureCM and Agile

 

In this post I would like to explore more of the Agile Manifesto and how it relates to software development and to delve into some of the reasoning behind why PureCM was designed and built the way it is.

Individual interactions over processes and tools. A cynic might look at this and say this means there is no need for software tools, but that's the point at all. Software tools are helpful and in many cases necessary but your tools should not define your process and you shouldn't be overly dependent on tools for communication. In Agile the right process is the one that works and over time teams might be changing, tweaking, rearranging process to find what works.

In order for an SCM system to be effective in this type of environment in needs to be flexible and adapt to the process instead of imposing process. The right tool is the one that works for you. I want to mention a long time complaint I have had with several SCM systems that impose process either intentionally or through lack of capability. For example AccuRev is a  system where mainline development as an intentional strategy is not supported and Perforce, VSS, CVS only mainline development as a strategy is supported (generally speaking) due to lack of capability.

PureCM has the ability to do basic mainline or complex branch heavy development strategies with any number of combinations in between due to not having a locked workflow and while also having strong capabilities which allow users to adapt PureCM to their process and not the other way around. Change is continuous in the agile flavors and unless it's not practical to think one could go out and buy a whole new set of tools after each tweak to the process, so having tools that can adapt with the right amount of configurability (built in options) is important.

Working software over comprehensive documentation. This entry in the manifesto is a cross-hairs pointed squarely at the waterfall process where every feature and function is documented in great detail before a project even begins. This approach has many pitfalls but in brief what you end up doing is either wasting a ton of time documenting features that never get built (for whatever reason) or adhere so strictly to the original documentation that you lose all ability to adjust to changing market/customer/technology demands over time.

PureCM has adopted a strategy to manage metadata information at the most minimal levels but I will detail this with when I get into Scrum, in short the PureCM task can be reduced to a one-sentence entry and expanded upon over time, detail increases as priority increases so you only spend time documenting features with a high probability of going into development.

Customer collaboration over contract negotiation. Here is part of the manifesto that puts emphasis on including the customer or the key stake holders in the software development process. This can take on different forms in practice from user acceptance testing by the customer, or demo of new features after increments.

PureCM can be a facilitator to this process but it depends on how collaboration is defined and adapted by the team, I will provide several examples once we are Scrumming.

Responding to change over following a plan. Another pitfall of the waterfall process. A lot of software teams might spend months or years working on a project using the original requirements documentation approved by the customer only to find at the end of it all the customer was not happy with the result or conditions in the market had changed enough to make features obsolete before they were even released. With the Scrum adaptation instead of planning out an entire project and a year's worth of effort in advance you plan out short increments called Sprints and this allows priorities to shift in short time to meet the changing demands of the customer.

 

With PureCM it is possible to actually manage your software development effort by sprints and I will get into greater detail in forthcoming posts so stay tuned!

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.

 

PureCM can now handle thousands of open features

One change which you will probably not notice after installing 2010/2 is that submitted changesets are automatically merged to features in the background. If you work in a larger team with many developers using features then you will soon see the massive performance improvements.

Prior to 2010/2 when you submit a changeset, this changeset is automatically merged to all features as part of the submit. This means that you are waiting around for this to finish until you can carry on working. Plus the server is locked so other users cannot submit until all the automatic merges are complete. This is not a problem if you have 5-10 open features, but in a team of 100+ developers this can turn into minutes.

With 2010/2 after you submit a changeset it is not automatically merged to any features immediately. If you go to the Merging view you will see that the changeset appears under ‘In Progress Changesets’ for each feature.

 

The server will then merge these in-progress changesets when it is not busy. So you are not waiting for the merges to complete and the server does not prevent other developers from submitting changesets.

Another neat feature with 2010/2 is that you can move unmerged changesets into the ‘In Progress’ state. So if you have hundreds of changesets to merge into a stream you can simply select all the pending changesets and select ‘Move to In Progress’. You can then carry on working while the server processes the changesets in the background.

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

 

SDC, Part 13: Rescheduling (and the consequences for work in progress)

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.
We'll now make a pause in our blog series, look at feedback we get from our readers, and then start filling the gaps. Any comments about topics you'd like to see here are highly welcome!

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 11: Fixing a bug on a live release

In this blog we will look at how to use PureCM in the process of fixing a bug in a live release. As a developer will probably already be working on 'the next release' it is important that switching to a previous release (to fix a bug) is as uncomplicated as possible.

PureCM provides the mechanism for a developer to work on a fix for an old version, and create a new release, without affecting his current development environment – or have his current development environment affect the bug fix environment (parallel development) … So how does it work?

Raise the task

The first stage is to raise a new task on the specific version of the project. A developer can then simply go to his 'My Tasks' view and click on the 'Start' button to populate his workspace with the code of the relevant version. This will avoid inclusion of any new changes that have gone into subsequent versions.

We've already covered how to create a new task, assign it to a developer and start work on it. So assuming that is all in place, the next step is to actually fix the bug.

Annotated File History

This is a good time to highlight an older feature of PureCM that proves very handy in the process of investigating and fixing bugs.. 

We will assume that the developer has debugged the release and managed to isolate the code that is causing the bug. If it is not an obvious bug, then in order to establish if the code was deliberate or just to find out why it was written, then using the annotated history can help…

This provides a quick way of navigating to the changeset that the code was implemented with thus providing the developer with the description, and if this is not enough to make a judgment on how to proceed then the changeset also provides the name of the developer who made the change – a short conversation could clear things up! As well as 'why' the change was made, it could also be useful to know 'when' the change was made in case an older release needs to be fixed.

Now the bug is fixed, the developer has completed some local testing and is keen to get this fix to the customer as soon as possible, therefore a new release is required. Clicking the 'New Release' option on the Version performs this task.

Tim's blog on creating a release has covered the details for this and how to deploy the release files to another machine, typically to build it.

Merging the change into relevant versions

The last stage in this process is to ensure the fix finds its way into other relevant development versions. This can be achieved by using PureCM's merging capability, even automatically using the 'Merge Rules' functionality. 'Merge Rules' will be described in detail later on in the SDC blog series.

So assuming merging is not done automatically, the owner of the target version can manually perform the relevant merges by navigating to 'My Tasks' where any Pending Changes (per version) will be listed ..

Here, I'm the owner of 'Version 2'. Pressing the 'Show' button reveals the list of changesets pending merge into this version. Right click the relevant changeset and choose 'Merge Change' (or 'Exclude' if you don't need this change).

In Summary

Fixing a bug on a live release can be achieved quickly using PureCM ..

  • Create a task specific to the version
  • Use Annotated History to understand the reasons and history of a change
  • Create new release based on the fixed version using the 'Create Release' functionality.
  • Ensure the fix is merged to the relevant Versions using PureCM's merging functionality.

The next blog will look at merging and merge rules in more detail.


SDC, Part 10: Creating a Release

In the last blog Kenji took a good look at some of the current and upcoming reporting systems inside PureCM. Today I'm going to take a closer look at Releases.

What is a Release?

A release is a snapshot of the code at a specific point in time. This gives you a permanent copy of your code at a specific point, which typically will remain read only. You can directly browse the content of a release and use it for internal/external/beta/etc builds or to send to your testers. Having a release gives you an easy way to tag points in your development and keep track of who is running which version of the code.

Make a release from a feature!

You don't just get to make releases of your versions. If you want to send a feature for testing before it gets integrated into the version you can also make a release of the feature.

How do I know what is in a release?

The quickest way to find a release is to navigate to the relative version/feature in the projects view and select 'Show submitted tasks and releases'. This provides you with a list of all of the changes that have gone into the version and shows at which point your releases have been created.

This gives you a very quick way to see what changes made or missed each release and also provides the interface to do more with your releases. Viewing the files contained within the release for example can be done by selecting the release and selecting the 'Show Files' option.

Seeing what files has changed between releases in very simple as well. Simply select two releases from the list and select 'Compare' from the menu. This will launch the familiar stream comparer tool which will show the files from both releases. If you are only interested in what has changed you can filter out the matching files in the options menu.

Getting the release on your local machine

The best way to get the release files to where you need them is to create a workspace. If you have an old workspace you can switch you can find your release in the 'Projects' tab listed under the correct version. Alternatively, you can simply select the correct release in the projects view as talked about above and choose 'Select Workspace'. Of course, creating a workspace to deploy a release can be scripted, e.g. using one of our build tool integrations, the command line interface or the .NET and Java APIs.

Summary

  • Releases are snapshots of your code at a specific point in time
  • Releases can be made from both Versions and Features
  • You can view your releases by selecting 'Show Submitted Tasks and Releases' in the Projects view.
  • You can get the files by simply creating a workspace.

In the next blog Lee will take a look at the process of fixing a bug in a current live release without including changes from ongoing development; the basic case of parallel development.