DVCS Offers Huge Gains and will be Next Generation Version Control
Understanding DVCS for Version Control
Distributed version control systems (DVCS) have made huge gains in adoption over the past few years and GitHub in particular has really brought DVCS to the geeky masses in a way that indicates to me that soon enough the only centralized VCSs left will be legacy systems. I know there are still a few reasons some folks prefer the simplicity of something like Subversion (SVN) and I don’t think there should be any rush to migrate large legacy code bases from more “modern” centralized tools like SVN or Perforce.
On the other hand, Git et al. are really not that complicated and the ease of branch and merge in a DVCS compared to SVN enables a great workflow for just about everything Agile, from TDD to Continuous Integration. If you are so unfortunate as to be running an older tool like ClearCase and compare this to the raw speed and branching/merging experience of a Git or Mercurial and then compare the price … well let’s just say that IBM’s got a good thing going.
Sure, DVCS is not perfect, for example storing large binary files is a pain (why are you doing that again?). Also, like any tool, folks take some time to wrap their heads around new concepts before they are comfortable and by the time you scale to development organizations that number in the hundreds (or even thousands), there are going to be some organizational and engineering challenges. Nevertheless, in this same environment, Agile is everywhere and Centralized VCS faces some pretty serious challenges for large geographically distributed organizations (last I checked, globalization isn’t going anywhere). From my perspective, the writing is on the wall, it’s only a matter of time …
The enterprise is a fickle beast …
That said, “only a matter of time” can be an eternity in the enterprise world and even though the productivity benefits a of DVCS are pretty clear, new technology always faces an uphill battle in large organizations, especially when existing tools are seen as “good enough”. Here at OpenMake, we know all too well how the enterprise can ignore hidden time sinks with negative impacts for the ALM process (see manually scripted builds. So with that said, I’m curious, what is the biggest thing holding back DVCS from getting more traction in the enterprise?
The best answer I can come up with is that, like almost everything in enterprise IT, it’s often more a matter of people and the ecosystem around a technology rather than any one thing specific to the technology itself. We see this all the time with our ALM automation solutions. Once enough people are familiar with the ideas and there are enough resources for those who aren’t, the switch flips and it becomes a no-brainer for the organization.
So, if all it takes is a critical mass of knowledgeable folks, what will it take for the enterprise IT market to get there on DVCS? Communities like GitHub and the broader open source community certainly are driving a lot of interest in DVCS, especially for the younger generation. What’s more, I’ve found many SCM administrators in the enterprise who say that their developers are already using DVCS, whether it’s supported or not. On the side of visibility and mindshare, I think we are almost there.
While it’s true you have to have the internal knowledge and expertise, most businesses will also balk at any tool that lacks rich tools and support. With Git at least, I get the sense that the IDE integrations and GUI tools are at the level of maturity (or close enough) to make it a good choice for enterprise development teams and of course, everyone sells Git support these days. But then when you are talking DevOps (see SCM and ALM), the developer story is only part of the solution. What about what the rest of the organization needs out of VCS?
Can DVCS deliver?
I think tools like CollabNet’s TeamForge and Microsoft’s Team Foundation Server are on the right track by adding DVCS (in this case, Git) support to existing enterprise-class ALM tools. Access control, issue tracking, and the capability to integrate with other important pieces of the ALM workflow (say, Meister and Deploy+) more or less completes the tooling puzzle, but even still, Microsoft and CollabNet will both tell you the move to DVCS is still not for everybody.
Even if you consider DVCS superior in every way (I”m not interested in that holy war), the cost of a large VCS migration project is not something to be taken lightly. That value proposition and migration path have to be crystal clear. You do not want to be THAT person, who championed a major infrastructure change only to discover that your existing processes are so closely tied to the old systems (e.g. our old friend, static build and deployment scripts) that the project runs seriously over budget and oh, by the way, audit compliance means you have to maintain both systems for years to come. There’s a fine line between running older systems because they’re well understood and battle-tested and being stuck with obsolete technology that represents it’s own form of technical debt.
All things considered, I’m not sure that 2013 is THE year for DVCS in the enterprise, but I think all the components are there and I would not bet against it.