Making Subversion Agile

It’s been ten years since the Agile Manifesto was published, and agile is still a buzzword for the software industry. When employed correctly, agile practices can save on costs by promoting flexible, incremental development, a continuous integration environment and effective communication between team members, and between the development team and the customer. Agile practices can help organizations avoid unplanned rework and QA, and ultimately hit deadlines. Crucially, the Agile Manifesto focuses on the realities of software development, rather than on documentation, plans, contracts, processes and tools. The values that form the cornerstone of the Agile Manifesto are:

  • Individuals and iterations over processes and tools – find the tool that allows your particular team to implement a successful workflow, regardless of whether that’s a high-tech or a low-tech approach. Selecting the wrong tool can distract developers from every agile project’s ultimate goal: delivering value.
  • Working software over comprehensive documentation – documentation is important, but in agile, working software is the ultimate goal, and producing exhaustive documentation should not get in the way of that. It’s all about finding the right balance.
  • Customer collaboration over contract negotiation – regular contact with customers increases the chances of discovering problems early on, before they begin to snowball out of control.
  • Responding to change over following a plan – plans are subject to change, as new information, requirements and challenges emerge. Agile teams need to be able to respond to these changes.

Also worth considering when adopting an agile approach, are:

  • Feedback – constantly evaluate your working process, to ensure you are adding the most possible value. This is essential in fast-moving teams.
  • Have working code at all times – executing application code is the best sort of feedback on the health of a project. In addition, a broken build forces teams to delay sharing changes, which ultimately leads to riskier integrations. Nothing slows down a team like a broken build.
  • Continuous integration environment – frequent, ongoing quality control over the traditional practice of applying quality control only after development is complete. This typically reduces the time taken to deliver software.
  • ‘Everyone is responsible’ – it’s important to maintain a culture where everyone is responsible for maintaining working code. A broken build should be an all-hands-on-deck task.
  • Incremental development – frequent integration, testing and evaluation of code is crucial to agile development, allowing problems to be detected and resolved earlier, and helping to maintain working code.

An effective SCM solution is a crucial factor in becoming agile, and there are several options open to organizations who want to implement a Subversion-based SCM solution:

1) Central Subversion Server

A central Subversion server does have the advantage of all developers working from a single, consistent copy of the repository. There are also advantages from an administrative perspective, because there is only one server at a single site to worry about. However, as the number of remote sites and users grow, the coordinated performance between the central server and remote locations can become an issue. This encourages developers to checkout infrequently, which makes continuous build integration impractical as the latest changes aren’t available from all development sites. Ultimately, you only uncover merge conflicts and other problems when remote users finally commit their code, and this has to be addressed manually, often requiring significant, unplanned rework and QA.This can cause deadlines to slip. The single point of failure inherent in this approach, prevents users from accessing the single central repository when the network connection is lost, the server crashes, or it has to be taken down for routine maintenance.

2) Proxy Server

Proxy server, master/slave solutions such as svnsync do provide local access to read only copy with the master, which partially solves the access and availability issues for remote developers, but commits and other writes can only be performed against the master. In some respects, proxy server solutions have the same single point of failure and latency issues, as a single server architecture. Sites can often end up working with stale versions of source code files, due to time lags between changes being written to the master repository and those being replicated to the read-only slave. Consequently, you end up with much of the same merge conflicts and broken build issues encountered with a central server architecture. The other factor to take into consideration, is that with a proxy server solution there’s no built-in capability for catching an error and retrying the failed transaction.

3) Subversion MultiSite

WANdisco’s Subversion MultiSite solution combines Apache Subversion with value-added functionality designed to help teams stay agile:

  • No single point of failure – all repositories are fully readable and writeable, and remote site developers aren’t dependent on the centralized build team if they need to do a build and test. This eliminates the potential bottleneck of a single point of failure.
  • Automated failover – allows individual servers or an entire site to be taken offline for planned outages without interrupting user access, making full 24-by-7 operation possible.
  • Built-in continuous hot backup and automated recovery – Replication is triggered automatically whenever a user connected to any server issues a write command. The commit is then propagated out to any other sites, ensuring that distributed repositories are kept continuously in sync. Whenever a server comes back online following an outage, it automatically resynchronizes with the other servers in the cluster. Third party solutions aren’t necessary for backup recovery, and the risk of data loss and extended downtime associated with manual recovery are eliminated.
  • Continuous build integration – MultiSite’s peer-to-peer architecture, unique active-active replication capability, and functionality for keeping distributed Subversion servers in sync, provides the support necessary to maintain that all-important continuous build integration.
  • Run builds at every site immediately – eliminates the time wasted while waiting for a build to happen in a different time zone.
  • LAN speed performance – users at every location experience LAN-speed performance for both read and write operations.
  • Rapid identification of problems – thanks to the Active/Active Replication technology, merge conflicts and other problems get caught and fixed as they occur. This is essential to recreate the same development experience that exists when everybody is in the same location.

For more information on the benefits of Subversion MultiSite, check out Forrester Research’s Total Economic Impact study of a Global Fortune 500 company using Subversion MultiSite.

2 Responses to “Making Subversion Agile”

  • Hi Jessica,

    Your opening statement for this post is probably inaccurate. Agile is no longer a buzzword, it is really and it exists, and it’s more and more adopted by companies, although, in my opinion, it doesn’t provide any advantage over waterfall, Agile can also be combined with Waterfall. Agile, however, seems to be suffering from a lot schisms over what’s Agile and what it’s not.

  • I really like this article, will have to look into your product. There are several of your bullet points that I need to follow up on.

    RE: Agile vs Waterfall
    Back in 1993, Waterfall as described in the tome “Code Complete” had already morphed a great deal from it’s beginnings. Who runs straight Waterfall even circa 2002? Here we run what I suspect many shops do – a quasi Waterfall- Agile methodology.
    Developers love the looser restraints of Agile, but project managers love the more sharply defined milestones.



Leave a Reply