Challenges

About three years ago, the PlayPhone Europe development team, consisting of 8 developers, began deploying Subversion (SVN) as their version control system. In the beginning, it was used in a very simplistic way. The code was being managed in a simple way, and deployed through a custom web site, that allowed publication from development to pre-production and production and also with reversion if needed. The problem with the approach was that it was impossible to release single bug fixes without a full site release.

Simon Rose, Director of Infrastructure at PlayPhone Europe, explains the challenges the team was facing: "Whilst the website tool was a great help to our operations and development teams, the code was too bespoke, and the knowledge of the process was held by a single systems administrator. When he left, there was a significant risk and impact on the business when problems occurred in the deployment process. Also, whilst the simplistic approach was fine for such a small development team, as the team has grown, that approach no longer met our requirements. We had often discussed the need for a more granular capability in our code management and release mechanism, and decided to revamp the whole process."

Solution: Change and Release Management Policy

When PlayPhone started tackling the problem, the current situation was first thoroughly analysed. An Ibuildings professional services consultant gave advice on how the repository should be used and on the correct processes and tasks to reach the desired goals. The solution was to replace the old system with a simplified but more than functional deployment tool and introduce some guidelines for its usage along with more general advice on the usage of SVN in the organisation.

The Ibuildings consultant first met with the team to discuss their requirements, and then produced a detailed specification. This included the definition of new procedures, training and development of the new deployment tool. The key area in this work was the definition of solid procedures for the team to standardise their usage of SVN. This is what we call a 'Change and Release Management Policy' (CaRM).

The goal was to allow

• Multiple developers to work together (often on the same files) without conflicting
• Developers to commit their work into the repository (even if it is incomplete or contains errors) without affecting others
• A developer to access the source code for any historical release and apply bug fixes to it
• Different teams to deploy both PHP and Java applications in a consistent manner using the same tool chain

The Results

Simon outlines the lessons learnt during the process: "Clearly defining the objectives of the consulting and training is crucial. Having an independent, objective consultant showing us how to use SVN properly and efficiently helped the team understand what needs to be done, and what can be done, to improve the existing practices." He also emphasises the importance of clearly communicating the ramifications of such changes to everyone involved and scheduling changes to occur during quieter periods in the business cycle.

Despite the complexity of the original deployment, the final outcome is that the old system has been wholly replaced. The team is now deploying using the new tool with proper documentation. They have been trained to use the version control system effectively, and they are now able to manage and support the code themselves.

According to Simon, many benefits have already been witnessed following the improvements. "Previously, we had a catch all process with no way of tracking every bug fix made and we had a bespoke system that could not be easily maintained. Now with a more granular approach to code release, we have a deployment process that is more efficient and causes fewer disruptions to our release cycle, and an improvement in the general understanding of the release mechanism."