DevOps, What’s it all about? Part 2 — Tooling! Git, the master of version control systems.
How can you bootstrap a culture if you don’t have the right technological tools? Let’s talk about version control and DevOps.
“an unpleasant or contemptible person”. — The Meaning of Git
General
In my first article, I tried to explain what is DevOps. I defined it as a movement or a methodology, which needs to be at least half made of cultural and organizational transformations. Having the right mindset and culture are great merits for an organization, but not enough on their own to help it prosper. It needs the right set of tools. One of them is a version control system. What’s that you might ask? Grab your self a cup of hot chocolate and let me tell you a story.
In short — whats a version control?
Version control changed the way we deliver and maintain software. It is a system that records changes to a file or set of files over time so that you can recall specific versions later. Version control means that you can track the changes over time, and if things go wrong you can revert to the last known version easily.
For many years we used centralized systems (such as CVS, Subversion, and Perforce) that had a single server which contained all the versioned files, and several clients that checked out files from that central place.
Those systems offered a better option for developers than saving files locally but were prone to many problems. They were a single point of failure, hard to maintain and not so easy to use. We still needed a step forward to be more agile.
The distributed version control system was the next evolution of those systems.
But what’s the difference? The clients don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history. Every clone is a full backup of all the data. This feature allows the client to work against many remote repositories, or to add users from other organizations to your repository, making life much easier.
Enter Git
Git became de facto the standard application when working with decentralized version control, for the following reasons:
- It comes with any Linux distribution
- It’s fast, developers save a lot of time
- Hard to learn, but when you understand it — it makes your life easier
- You can easily go back if you made a mistake
- Work offline and commit later
- Its got a really big ecosystem with Github, Gitlab, and others
- Its got plugins to any IDE or editor
- Makes collaboration easy
Git Concepts
After you save your work, Git stores a commit. A commit is a snapshot of all your files at a point in time. Git will not save unchanged files. Committed snapshots can be thought of as “safe” versions of a project — Git will never change them unless you explicitly ask it to.
Git uses SHA-1 hash to add a unique identifier to commits. but what does that mean? SHA-1 will it takes some data as input and generates a unique 40 character string from it. This means that no other input data should ever produce the same hash.
Commits create links to other commits, forming a graph of your development history. Commits are identified in Git by a unique hash of the contents of the commit. Because everything is hashed, it is impossible to make changes, lose information, or corrupt files without Git detecting it.
Each developer saves changes in its local repository. This means that you can have many different changes based on the same commit. Git can deal with those remote changes using Branches, which are pointers to work in progress, managing this separation. Once your work created on a branch is finished, you can merge it back into your team’s main branch.
DevOps and Git?
But how does this relate to DevOps you say? Git allows us to have a single source of truth (at least from the ideal point of view). This knowledge can help us have the information we need to push the DevOps transformation forward. Since Git is used by developers and operators nowadays, it helps both teams to have better communication.
One of the pillars of the DevOps methodology is to automate things. A CI/CD pipeline or Continuous Integration/Continuous Deployment is the backbone of the modern DevOps environment. The main benefit is the automation of the building, testing, and deployment of applications. Git fits well into those concepts and some implementations of Git gives you a full pipeline that could make the work of integration much easier.
Using a CI/CD pipeline would allow you to catch bugs and errors early in the development cycle, it would save you expensive manpower, that used to test, debug, build, and deploy manually your code.
Git even fits into the concept of infrastructure as code if our hardware and infrastructure become some code and configuration files, why not apply the same method as the code that software developers use? If we want we can revert to last known configuration and we can see all historical changes and work on our infrastructure remotely.
I know that most of the other distributed version control systems can offer the same benefits, but for some reason, Git became a standard, i moved from Subversion to Git, and i am not that special, Git is everywhere.
Git and DevOps Culture?
Now i would like to see how we can use Git to have a better working culture. By design, it will encourage your team to collaborate on their project. Everyone could see and react to other’s work in real-time, fact is that each developer should write a well-written comment when he makes a commit. This whole process when done correctly, might help your team to become more DevOps oriented. When done in a bad way, it might turn the developer’s life into the hell of white noise and endless pointless discussion and fights.
For example, let’s talk a bit about the idea of “pull requests”. Pull requests combine the review and merge of your code into a single collaborative process. Once you’re done your work on a branch, create a new pull request. You can add members of the team to the process, and they should review and vote on your changes. A pull request can be a good option to exchange ideas, to make the overall code that the team is writing better. A team can agree on how and what to write there, and who should be the reviewers. Yet again they can become tedious and annoying work in the wrong hands. When the communication is bad on a personal level the pull requests would represent that. As one developer told me, i mainly review pull requests every day and i don’t like it.
Github and Gitlab?
I think it would be a bit awkward to explain Git and not mention Github and Gitlab. GitHub is a collaboration platform for developers based on the Git system. It allows the developer to collaborate remotely using UI or command line, but Github is more than just a version control tool. It has project management abilities, automation with “actions” and the option to integrate with almost any possible tool that developers might use. Github is easy and friendly to use and since its a managed service, many companies would prefer to start using and run self-host.
Gitlab is another known platform that is based on Git. I think that Gitlab is more focused on “DevOps” features, they offer excellent CI/CD abilities which is very cool.
So what are GitOps? We all use Git in our pipeline, is that GitOps?
One can take this approach to the next level when using some tools that have been labeled as GitOps, i find the whole term a bit weird since any company i worked for had some sort of automatic pipeline with Git, so to some extent, all them were doing a bit of GitOps, but maybe that’s, not exactly the whole idea. GitOps mean that operations are done mainly with Git commands and concepts, for example, one would not update his Kubernetes cluster with Kubectl -f xxx.yaml but with Git commits.
Next time we will unveil something of the secret art of CI/CD pipeline!
Do you some questions about DevOps and tooling? feel free to contact me or anyone at our team at Polar Squad, Empathy is one of our values, and now might be a good time to start doing some first steps in the realm of DevOps transformation, feel free to drop us an email or Linkedin message! maybe we can help you, or guide you in the right direction.
