Selecting the right version control system – Part 1: Centralization
A critical backbone of any DevOps environment is the version control system (VCS). Fundamentally, version control systems are change management enablers; they track changes by each contributor across a body of information (typically text-based) that together comprise a complete version history. A VCS supports collaboration, incremental delivery and controlled enhancements.
VCSs have gained notoriety with the advent of automated system deployments that rely on configurations, recipes or patterns describing how, where and in what order systems should be deployed. This “inf
When working with any VCS, there are two primary modes: edit and checkpoint. During edit mode, a developer, administrator or configuration manager changes the state of the technology solution. As noted, this could be a dependency (which is best recorded representationally as a pointer or link to the binary dependency), a software module or a system configuration and deployment setting. Once the editor has determined that the changes have moved the solution to a new, valid state, the editor checkpoints the changes through a commit operation. The effects of and strategy behind the commit operation vary by solution; however, all solutions save the state change and its history.
Across the industry, there are two strategies for managing revision history across commits: centralized or distributed.
1.Centralized version control
A centralized VCS (CVCS) manages a state from a single, collective location. There is only one canonical record of revision history that is centrally stored. Popular examples of centralized VCSs include CVS, Visual Source Safe, IBM
Without an active connection to the central server, editors are severely limited in their ability to commit changes, compare their changes with previous versions and get the latest changes that other editors have committed. Not all software projects are centrally located and accessible. Some projects are globally distributed or partially at a customer site where outside network connectivity is blocked. In this situation, editors cannot incrementally commit their changes to the master and are forced to mash feature additions into a single commit.
These restrictions are not always negative. Centralizing revision history lets administrators more tightly govern valid editors and commits. Only certain users may “check out” the state of the software at a given time, and a limited number of editors may commit changes. This provides the added security benefit of protecting intellectual capital: no single user has the complete history of the software.
2.Distributed version control
A distributed VCS (DVCS) provides full revision history to all subscribers. There is no inherent notion of a master or gatekeeper as with a CVCS. This model provides complete flexibility in configuration management. Examples include Mercurial and Git. Editors may be disconnected from the network and able to continue committing changes to the local repository, which holds the full revision history. But what about when it’s time to merge changes with others in the team? This is where a DVCS will provide a merge capability, such as push or pull, to share change sets.
DVCS provides complete flexibility to customize your DevOps configuration management however you would like. There is no need to keep a central repository, although many teams bless a server as the central build server. Teams may share change sets when most appropriate. Most important, editors are able to commit local, incremental changes without affecting the entire state of the project. However, the freedom and flexibility comes with a governance cost. Where a CVCS allows teams to more rigorously define processes with respect to the central repository, processes are much more difficult to define and maintain with a DVCS. It is nearly impossible to silo or protect interaction among teams in a distributed model.
Configuration management in DevOps depends on a version control system that can manage state and associate builds and releases with an overarching system state. When selecting the best VCS, DevOps administrators must choose whether a tightly governed centralized source management solution is more important than a flexible distributed model.
Which VCS have you selected, and why? Please share with me on Twit