The Next Frontier of Enterprise Software Development: Social Coding For Subversion

WANdisco recently unveiled uberSVN - a major new product available free of charge that transforms Subversion into an open, extensible platform for application lifecycle management (ALM) . In addition to plug-and-play flexibility and rich system and user administration capabilities, uberSVN provides the first-ever social coding environment for Subversion, taking enterprise software development beyond the limits of email, wikis, defect trackers, peer-code-review-tools and other applications typically used to manage projects.

uberSVN’s social coding environment reflects the convergence of social networking paradigms represented by Facebook and Twitter that foster instant communication and the collaborative development models of open source communities where software with features similar to these social networking sites was first used. And it’s having the same positive impact on software quality and developer productivity behind corporate firewalls that it’s had in the open source communities that deliver such market-dominating software as the Apache web server, Linux operating system and even Subversion itself.

uberSVN is organized around development teams and their activities. Each team has a home page that profiles the team members, lists the projects they’re working on, repositories they’re using and their latest activity and status. Team members can see each other’s real-time progress by simply subscribing to Twitter-like feeds that managers can also monitor.

With uberSVN, just like developers in an open source community, software engineers in corporate IT environments can rapidly exchange information and continually learn from one another. The overall skill level of the development team goes up and the all-too-common pitfall of reinventing the wheel is avoided. The end result is higher quality software delivered in far less time.

uberSVN is free. Download it now at: http://www.ubersvn.com/download.

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.

Keeping Multiple Subversion Repositories in Sync

With Subversion 1.4, svnsync was introduced for this purpose. The key problem with using svnsync for multiple Subversion repositories distributed over the WAN is its reliance on a master-slave architecture. While svnsync does provide the advantage of having local read-only repositories at each of the remote development sites, only the master repository is writeable. The master repository is then replicated to the read only slaves. However, the replication process can place a significant load on the network and servers. Because of this, replication tends to happen on an infrequent basis, leaving the read-only slave repositories that remote sites do their checkouts from out of sync with the master much of the time. As a result, commit failures due to update conflicts on the master repository can become a problem. In order to avoid commit failures, developers at the slave repository sites have to do updates over the WAN against the master Subversion repository before doing their commits. This can negate most of the expected network performance and developer productivity benefits of using svnsync in a distributed development environment.

Other solutions such as svk do allow multiple repositories to be readable as well as writeable, but there are no guarantees of consistency across the repositories. A commit can succeed on a developer’s local repository where there are no conflicts, and fail when it’s copied to other sites’ repositories due to update conflicts. This can make administration extremely difficult.

WANdisco solves these problems by turning distributed Subversion repositories into peers. All of the repositories are writeable, and consistency across the repositories is guaranteed. WANdisco’s active-active replication capabilities allow developers to work at LAN speed over the WAN for both read and write operations, while keeping all of the repositories in sync, in effect in real-time. WANdisco also provides self-healing capabilities that automate disaster recovery after a network outage or server failure.