In DevOps, the goal is not only to excel in producing applications. It is also to control all of the technology infrastructure through code, including integration testing, deployment server configuration, monitoring, and reporting. Once the code is in place for any of these items, it can be automatically triggered and executed. This code-based approach is what makes continuous delivery possible in DevOps: applications flow from their creation by developers through to their deployment in the real world of production.
Code version control is therefore vitally important to successful DevOps. Application code branches must be correctly merged for continuous integration testing. Infrastructure configuration code must be available in the latest version to operations staff for deployment. Version control systems can also hold configurations for performance monitoring and log management systems. In addition, clear records of which code changes were made where, when, and why are crucial for speedy problem resolution.
Although today’s popular version control systems have similar goals, they have different strengths and weaknesses:
- Git. Developed from the start as a distributed system, Git has no centralized base for files. This allows you to have multiple redundant code repositories and multiple branches of code that can be worked on, online or offline. Because Git operations are mostly local to each repository, network latency is not an issue and Git is relatively fast.
- SVN. Apache Subversion, or SVN for short, is single server-based, instead of being a distributed system like Git. SVN takes the most practical features of an older system called CVS (still in use) and adds more of its own. In particular, it prevents corruption to the database of code revisions by using atomic operations. Atomic means that changes to source code must be applied fully or not at all: partial changes are not allowed. Very popular, SVN is slower in performance compared to Git, although easier to use.
- Mercurial. A direct competitor to Git, Mercurial also uses a distributed model. It is written in Python and as so already likely to be of interest to Python language developers. Easier to learn than Git, it offers less powerful branch merging capabilities.
Which one should you use? If your DevOps team is smaller, SVN may be the better choice. For larger projects or ones in which several developers will be updating the code at different times, Git may be preferable. If Git is not favored by your DevOps team, for example, for reasons of lack of user-friendliness, Mercurial may be a suitable compromise. However, the following recent developments associated with Git may have solved any major usability issues:
- GitHub offers the power and functionality of Git, but with a web-based graphical user interface (Git has a command line interface.) It also includes collaboration functions, such as wikis, task management, bug tracking, and feature requests.
- GitLab also includes wikis and issue tracking, as well as LDAP integration to directory servers for tracking resources and user privileges.
- Bitbucket is similar to GitHub, although it is written in Python and can be used as a web hosting service for projects using Git or Mercurial.
Whichever version control system you use, each code change committed to the system can also be used to automatically trigger continuous integration and/or continuous deployment. Speed and reliability of releases can then go up, while issues and incidents go down.