The whole idea behind DevOps is to bring different teams together while providing a more elegant approach to source code management and deployment. This first layer we will peel from the DevOps fruit is Version Control. As we progress through the various areas of DevOps, I will detail how these core concepts work together as part of a meaningful DevOps solution. I’ll take this from an Azure DevOps view point but I assume these principles are common across other cloud providers. The idea behind DevOps is to provide a platform for areas like the following:
- Managing Source Code\Repositories
- Easier to Collaborate across teams
- Manage Deployment of a solution via Pipelines
- Using Service Connections to integrate with 3rd Party services
A solution can be considered a an application (like a web application) where Azure DevOps is used for managing the lifecycle of that application. It could also be considered a containerized solution where you are deploying docker images to a Kubernetes Cluster. You may be deploying an (IaC) Infrastructure as Code solution which is using templates/configuration files to deploy and/or maintain your infrastructure. Lots of examples here of what you can deploy but Azure DevOps is how you can store and manage the deployment of your solutions. In this blog post, I would like to provide a focus on Version Control as this is an extremely important concept to grasps before one starts diving into Azure DevOps:
- Version Control System and Repositories
- Branching
- Forking
- Pull Requests
Version Control Systems and Repositories
A version control system is a system that is designed for tracking source code during software development. This version control provides protection in that previous versions can be recalled. In older version control systems, a developer would check out a source code file and it would be exclusively locked while they working with it. This prevented other developers from working on that particular source code. The most popular approach is utilizing a Distributed Version Control System where developers can copy or mirror source code that’s hosted in a remote repository locally. They can work locally with that solution and after their work is completed, can commit those changes back to the remote locally and push it up to the remote repository. You have two main components that makes this happen.
- Remote Repository like a GitHub Repository or Azure DevOps Repository is a place to store source code.
- Git client which is installed on the Developers machine
Having a git client enables developers can work on the same code at the same time by having local copies. This adds flexibility and efficiency for developers by removing unnecessary roadblocks. So how does Azure DevOps fit into this picture? See pipelines next.
Branching
The next important aspect of a version control system is the use of Branches. You can think of branches as unique containers that contain source code. With a repository, you always start off with the main branch. You can work solely within the main branch and all updates to source code are pushed directly to the main branch. That is not an ideal approach in a real world enterprise environment. Instead, you can use git client to create new branches while copying source code from the parent branch. For Example, I can create additional branches (like a feature branch) which makes a copy of the main branch and any changes made to code in that branch are only applied at that level and the main branch remains untouched. At some point, you will likely merge a branch back into main branch. This is where an organization develops a branching strategy for how source code is shared and maintained. For Example, you may use short lived branches for hotfixes and that branch goes away once the code containing those hotfixes are merged back into the main branch. What’s great about a DevOps platform like Azure DevOps is that you can implement branch policies that give you some control so users can’t just merge any branch of code into the main branch. For Example, I may require a pull requests which requires an approver before that code is merged into the main branch.
Forking
Forking gives you the ability to take a complete copy of a repository by creating a fork and cloning it. You can also include all of the branches of that repository. This isolated in that it doesn’t touch the original source code. The more common reasons for forking is to make something new off of someone else’s existing code. Maybe add some sort of enhancement. The second common reason for forking is to correct a bug in an existing project. You may not have any relationship with the owner of that repository and fork his/her code and fix a bug and then submit a pull request and the original owner has the option to accept that pull request and merge that change into the original project.
Pull Requests
A pull request is a controlled mechanism that provides the ability to merge code from a source branch or repository into a target branch or repository. Lots of ways a pull request can be initiated. In the example above, I described a common way forking is done to correct bugs within an existing project on GitHub. In Azure DevOps, you can initiate a pull requests to merge one branch of code into another target branch. A common scenario is creating a pull request in Azure DevOps to approve and merge a branch containing a hotfix into the main branch. The great thing about pull request is it integrates an approval process so a pull request usually needs to be approved before a decision to merge is made.
Thank You,
Russ Maxwell
Resources
https://git-scm.com/doc
https://docs.microsoft.com/en-us/azure/devops/repos/git/?view=azure-devops
https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops