The most important technology decision with regard to source code control (SCC) is whether to host the repository on- or off-premises.
Developer commentary focuses mostly on technical details of SCC protocols; from an executive perspective, this is the moral equivalent of arguing Ford vs. General Motors in terms of whether the battery and fuel filler tube are on the driver or passenger side. At the same time, the application lifecycle management (ALM) literature too often tracks high-level vendor feature lists, and properly accounts neither for legacy requirements nor the new opportunities the expanding cloud market offers.
SCC is fundamentally a mature technology; while clever programmers continue to create new conveniences, the basics have been clear since the original Source Code Control System was developed forty years ago in Bell Labs. Most functionality can be "gatewayed" or translated between popular competing SCC servers. With sufficient motivation, a legacy repository can be "ported" to a new server by a mid-level administrator or programmer.
Developers passionate about selection of one SCC model over another are correct that there are real technical differences between the alternatives. At the same time, operation at that level is a symptom of deeper problems; with a few exceptions, a development organization frequently exercising advanced SCC features has workflows that are too complicated. Complex change requests that involve merging alternative branches for specific customers are good business for few teams.
Where to host the repository, though, and who maintains it, are crucial strategic questions. To see their pertinence, consider first the special characteristics of SCC.
What makes SCC special
SCC is rarely a "value-add;” even the front-line coders most involved with it want it just to do a few simple functions. SCC is judged in conservative terms; it needs to be available, predictable and reliable. It doesn't have to scale much -- successful businesses often are based on a shockingly small corpus of source code, and even something as large as an operating-system kernel fits in the corner of an iPod.
Also, as already mentioned, SCC experience has been widely diffused over the last four decades. Plenty of administrators have some familiarity with management of SCC.
Is that how you want them to spend their time, though? While SCC administration isn't now a deep responsibility, it can be a time-consuming one to ensure that backups, logins, free-space and so on are properly configured.
The alternative is to buy SCC as a utility. While most ALM descriptions haven't even considered this possibility, the latest generation of programmers is coming to think of it as the default: they're thoroughly accustomed to reliance on cloud services such as GitHub or Bitbucket.
Going to the cloud for SCC is independent of other IT decisions your organization makes. Whether you have an exchange server in-house, or buy mail service from a bulk provider, does not determine what's right for your SCC. Source code is a crucial organizational asset--but so are the organization's business documents and project plans. Even a decision that security or availability is paramount doesn't in isolation determine the right home for your SCC, because you still must decide whether you can better manage the security risks of maintaining an SCC server in-house, or through a contract with a specialty provider. As the landscape of digital threats becomes increasingly hostile, there's plenty to like in leaving security to specialists.
What remains essential are the fundamentals of good management: document your organization's specific requirements for SCC, the costs and benefits of different alternatives, what kind of disaster recovery each affords and your explicit decision. SCC meaningfully labels an essential tool-- the application of that tool ranges over a wide span of organizations and roles, however, and you can't assume that the right decision for a different team automatically applies in your situation.
Finally, recognize that, with the right preparation, the SCC part of your ALM is likely to be successful. Source code is so small, in comparison to the capabilities of modern servers, that you can readily experiment or hybridize different solutions. Your programmers most need from you a definite SCC plan, so they can move forward with the work where they do add value. They want to know how to get at “head” (a technical term in SCC theory), and will quickly adapt whether it’s “in the cloud” or “at home.”
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.
Dig Deeper on Topics Archive
How important is ALM process automation in a modern DevOps approach?
Create a holistic GRC system for SOA and microservices
Finding harmony between middleware tools and emerging apps
HP application lifecycle management: What you need to knowBy: Evan Dardano