Why am I writing this article?
I am learning about DevOps these days. As many people can attest, learning DevOps can be an overwhelming task. One of the techniques I decided to do to help me through this long and still exciting journey is to write and publish articles about topics I am studying.
The reason for doing this is I found out during the process of writing about a certain topic I actually get to know the topic on a deeper and more intimate level. Also, the fact that I know I will publish these notes on the wild internet beside my name makes me want to make sure what I write is correct and makes sense. Another benefit is hopefully if I say something wrong someone kind enough will correct me and this will improve my knowledge. Lastly but not least, by writing I am hoping to improve my written communication skills.
In this article, I will talk about version control from a high-level overview. So let’s get going!
Table of Content
What was the problem that inspired version control systems?
Imagine you’ve got this amazing idea for a mobile app, and investors are all in, ready to fund your project. You hire a team of developers to turn your idea into reality.
The developers split the project into two parts: one for the front end and one for the back end. As they start coding, they want to review the code to make sure everything’s going according to plan. But without version control, their options aren’t great.
Let’s say your developer’s team wants to discuss something in the code among themselves, they could have a meeting and present the code if the meeting is in person, or share screens if it’s a virtual meeting, another option is to save different versions of code files and email it to each other while hoping not to mess things up.
When it’s time to hand over their finished code to operation it will be a similar error-prone process. Emailing the code would be one option, using a network shared drive is a similarly bad option. As you can tell this is a disaster waiting to happen and soon enough one of the developers will overwrite the main file or delete something important. Also, there is not an organized way to tell who did what and when which makes measuring the productivity of the staff a difficult task and might even violate certain regulatory requirements.
Now, let’s introduce version control, a solution that keeps track of every change made to the code. Each developer can pull and push from and to the codebase, work on their part independently, make changes, fix bugs, and try out new features . With version control, they can merge these changes seamlessly and with confidence.
So, now your developer team can work confidently on their features and tasks, knowing they can go back to a previous version if something goes wrong. They can also see who made what changes, making it easy to find and fix issues. Code reviews become easier because they can compare different versions side by side.
Simply put, version control is a system that allows you to track changes to files over time.
What can we store in a version control platform?
Version control is well-known for storing software codes. However, the code is not limited to application code which is written by developers. Other types of codes are things such as testing code written by testers, infrastructure as code written by IT admins, configuration as code and even database as code written by Site Reliability Engineering (SRE) and DataBase Administrators (DBA) teams respectively.
It’s worth noting that while version control systems are prevalent in the software development industry, there are arguments supporting their use by anyone dealing with documents. Mohammed Radwan, a 12-time Microsoft MVP, Principal DevOps and Agile Consultant and my mentor, is one such advocate. He emphasizes that the functionalities and powerful features of version control systems surpass those of other document management solutions. Microsoft hosting its renowned “Microsoft Docs” on GitHub validates the practicality of this concept, also known as documentation as code.
What are the types of version control systems?
There are two main types: centralized and distributed.
- Centralized: All data resides on the server. Each change is immediately stored on the server (e.g., TFVC).
- Distributed: Each team member has their local copy. Changes can be introduced to the server when deemed appropriate (e.g., Git).
So, which is the better choice and why?
Distributed systems offer advantages in speed, as changes are made locally, reducing the need for frequent server access. Additionally, distributed version control allows offline access, enhancing productivity. This approach is particularly beneficial for open-source projects, aligning well with their collaborative nature.
Another important consideration is redundancy. By its nature, central version control systems are a single point of failure systems because it depends on one central server, while with distributed version control each user’s local copy is a complete backup of the entire project, including all historical changes. This decentralization provides several benefits in terms of resilience and redundancy.
While Git does not inherently have a central hub in its design, users have the flexibility to adopt a single central repository, like a remote repository on GitHub. This flexibility is one of Git’s advantages as it fits different workflows and teams` preferences.
For a more detailed comparison, I made this table below:
| Distributed (Git) | Centralized (TFVC) | |
| Version Control Model | Distributed model where each user has a local copy of the repository. Multiple repositories can exist. | Centralized model (client-server model) with a single repository on a server. |
| Exclusive Control Mechanism | No Exclusive Checkout, Supports Concurrent Editing. | Exclusive Checkout for Files. |
| History and Changes Tracking | Full Local History, Commits, and Changes Available Offline. | Centralized Tracking of History and Changes. Access to full history available only when connected. |
| Branching | Path-based branches for isolating risk among feature teams. | Lightweight and path-independent branches for flexible feature development. |
| Dependency on Network | Many Operations Can Be Done Offline. | Most Operations Require Network Access. |
| Suitability for Collaboration | Ideal for Collaboration on a Global Scale, Diverse Teams. | Suited for Projects Where a Single Source of Truth is Crucial. |
I will stop here and I will continue in part two of this series. See you later!
References:
Radwan, Mohamed. “Managing Version Control.” Fundamentals of Modern Software Engineering and DevOps course, Module 6. DevOps Visions. https://github.com/MohamedRadwan-DevOps/devops-step-by-step/tree/main/source/advanced-introduction-to-devops. Accessed on 8th December 2023.
Silverman, R. E. (2013). Chapter 1: Understanding Git. In Git pocket guide: A working introduction. essay, O’Reilly.
Atlassian. “What is Version Control?” Git Tutorials. Atlassian, https://www.atlassian.com/git/tutorials/what-is-version-control. Accessed on 8th December 2023.
Microsoft. “Comparison of Git and Team Foundation Version Control (TFVC).” Azure DevOps Documentation. Microsoft, https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/comparison-git-tfvc?view=azure-devops. Accessed on December 9, 2023.
