Monthly Archive for February, 2010

Making Subversion Agile in a Distributed Environment.

Agile development is iterative and incremental. It requires continuous build-test-deploy cycles and continuous communication. Your SCM, whether it’s Subversion or any other, is the key enabler for communication about the most important aspect of any software development project: the current state of your code.

The biggest challenge to effective agile development in a distributed environment lies in maintaining the same level of communication, the same level of continuous integration and the same level of Subversion repository access that’s possible when everyone works from a single location. While you can partially overcome the effects of distance by putting certain practices into place, the implementation architecture and tools you choose can either help or hurt your efforts to be agile.

Central Subversion server and proxy server solutions like svnsync often can’t address requirements for high levels of communication and continuous build integration in large distributed organizations because:

Network latency causes remote developers to check out source code and commit changes infrequently. Merge conflicts and other problems aren’t uncovered until later in the development cycle, resulting in broken builds, extra QA and rework.
The latest changes aren’t available from remote sites, making continuous build integration impossible.

Proxy server solutions such as svnsync have the same network latency issues for write transactions that central server implementations have. In addition, if the replication of a write transaction from the master to a read-only slave fails, with svnsync there’s no built-in capability for catching the error and retrying the failed transaction.
If an IT organization wants the flexibility to allow all of its sites to run builds in parallel so that remote developers aren’t dependent on a central build team’s schedule and time zone differences, this won’t be practical with a proxy server solution if build scripts include write steps that can only take place on the master server.
Agile development requires a high level of availability. Central server and proxy server implementations have a single point of failure inherent in their architectures. This limits availability when the central or master server crashes, the network connection is lost, or the server has to be taken offline for maintenance
If development takes place at only one location, with a large enough team, the combination of development activity and continuous build cycles on a central Subversion server can turn it into a performance bottleneck as well as a single point of failure, slowing down both developers and the build team.

In contrast to central server or proxy server solutions, with Subversion MultiSite’s peer-to-peer architecture there is no single point of failure, or performance bottleneck. Distributed Subversion servers are fully readable and writable at LAN-speed at every location and kept continuously in sync by WANdisco’s unique active-active replication capability. Each site can perform builds and test locally with the latest source code, regardless of where it originates. In a distributed environment, this provides the support necessary for continuous build integration that detects problems early and keeps software development projects from going over-budget. Delays caused by broken builds and scheduling conflicts with a centralized build team go away.

In addition, because WANdisco’s replication technology turns distributed Subversion repositories into mirrors of each other, continuous hot backup is achieved by default. Subversion MultiSite leverages this with automated recovery features that allow one site to recover from any other after a network outage or server crash. These capabilities can also be used to take servers offline for routine maintenance without interrupting user access, making 24-by-7 operation possible. As a result, Subversion MulitiSite delivers a higher level of availability in a globally distributed environment than a central server can with everyone at the same location. Downtime is eliminated and business continuity is insured.

Subversion Clustering is built on the same replication technology as Subversion MultiSite and delivers the same automated recovery capabilities that enable full 24-by-7 operation, with immediate and transparent failover. It allows Subversion to be deployed in an active-active cluster over a LAN and removes the single point of failure and performance bottleneck of a central Subversion server. It provides truly shared nothing clustering. There is no sharing of disk, CPU or memory between servers in a cluster. Intelligent load balancing capabilities optimize performance even further by taking each server’s current load into account before routing requests, rather than relying on simplistic round-robin approaches. Subversion Clustering is often used to improve Subversion’s performance by spreading the load created by continuous builds across a cluster of servers at large sites.

Subversion Clustering can be implemented standalone, or in combination with Subversion MultiSite to combine local clusters into an active-active WAN cluster that can be monitored and administered from one location. Remote users are routed to the closest site where Subversion servers are available.

Distributed software development reduces labor costs and provides access to wider talent pools and global markets. Agile development delivers cost-savings by catching problems before unplanned rework and QA leads to missed deadlines, and being flexible enough to allow software to change as fast as user requirements. In order to achieve this, the right processes have to be combined with the right technology to overcome the impact of distance on communication between developers. The bottom line is that when agile development is implemented successfully in a distributed environment, the greatest cost-savings and productivity improvements possible can result.


About Jim Campigli