How to become a DevOps engineer in six months or even faster. Part 3. Versions

How to become a DevOps engineer in six months or even faster. Part 1. Introduction
How to become a DevOps engineer in six months or even faster. Part 2. Configuration

Refresh the memory

In the first part, we talked about the culture and goals of DevOps, in the second – how to lay the foundation for future code deployments using Terraform, which itself is code. In the third part, we will discuss how to save all these parts of the code from complete mess. Spoiler: It’s all about Git!

Bonus: We will also talk about how to use this very Git to create and promote your own personal brand. The picture shows where we are now.

Why bother with this?

What is meant by versioning? Imagine that you are working on some kind of software and constantly make changes to it, adding or removing functions as needed. Often the last change will be a fundamental change, breaking everything created earlier. If you are a representative of an old school, you will probably name your first file awesome_code.p1.

Then you start making changes, and you need to save what works, in case you have to return to it. Therefore, you rename your file to this: awesome_code.12.25.2018.p1.

Everything works fine until, on the same day, you make a few changes and you have to name the new file awesome_code.GOOD.12.25.2018.p1. And keep up the good work.

Most likely, in a professional environment, you have several teams collaborating in the same code base, which further violates this model. Needless to say, this crazy train is quickly derailing.

Source Code Control Version Control System

Use the SCC version control system – this is a way to store your files in a centralized place where several teams can work together on a common code base. This idea is not new. The earliest mention of the SCC system that I managed to find dates back to 1972. Thus, the idea that we should centralize our code in one place is definitely out of date.

However, the idea that all produced artifacts should be versioned is relatively new. This means that everything related to your production environment should be stored in the version control system, subject to tracking, checking and recording the history of changes.

Moreover, the application of the law “all prod artifacts must be versioned” really makes you approach problems by the principle of “automation first”.

For example, when you decide to simply click on a complex problem in your AWS development environment, you can pause and think, “is this a click on a versioned artifact”? Of course, the answer is no.

While making quick prototypes through the user interface to see if something is working or not is normal practice, your work will be short-lived. Therefore, when doing promising and time-consuming work, be sure to do it in Terraform or another infrastructure-as-code tool. Remember – manage versioned artifacts and store them using the Git repository.

Git repository

Before Git, using SCCS such as SVN was awkward, not user friendly, and generally a rather painful experience. The difference with Git is that it provides distributed version control. Simply put, you do not block other users of the centralized source code repository while you are working on your changes, but you are working with a full copy of the code base. After you finish your work, this copy will be embedded in the master repository.

Keep in mind that the above is a gross simplification of how this works. This description is sufficient for the purposes of this article, however, a detailed knowledge of Git is a laborious but rewarding experience.

For now, just remember that Git does not work like SVN. This is a distributed source code (version) management system in which several development teams can safely and reliably work on a common code base.

Why do you need to know this?

I strongly affirm that without knowing how Git works, you will never become a professional DevOps (Cloud) engineer. How to study it? Note that a Google search result for “Git Tutorial” usually provides links to extremely bloated and confusing tutorials. Nevertheless, some really sensible textbooks come across among them.

One of such a series of textbooks that I recommend to everyone to read, study and use in practice is Atlassian’s Git Tutorials. They are all good enough, but one section, Git workflowsdescribing the workflows of this repository is used by professional programmers around the world.

Another really good tutorial is exploring the branching of the Learn Git Branching repository. Atlassian tutorials are built on the “read and learn” principle, and Learn Git Branching is an interactive tutorial. In any case, you will not go far in learning DevOps unless you understand how this repository works.

I note that a lack of understanding of how the Git Branching function works or an inability to explain what Gitflow is, drowns during an interview 99% of applicants for the candidacy of DevOps development engineer. This is the key point – you can come for an interview and not know Terraform or any other latest fashionable infrastructure-as-code tool, and this is normal, because you can study it in the process. But ignorance of the work of Git indicates that you lack the basics of modern best practices in software development, it does not matter whether it concerns DevOps or not. This signals the hiring managers that your learning curve is too uneven.

Conversely, your ability to speak confidently about the best practices of Git tells the hiring managers that you came up with the installation to do the software development first, and this is exactly the image you want to project. Conclusion: You don’t need to become the world’s leading Git expert to get this awesome DevOps job, but you need to live and breathe Git for a while to talk confidently about what’s happening to it. To do this, at a minimum, you should have a good understanding of how to do the following:

  • create a copy of the repository (Fork a repo);
  • Create a Git branch
  • synchronize the stream to the repository and vice versa;
  • create a pull request.

What’s next?

Once you learn the introductory lessons in Git, get yourself an account on GitHub. This is the most common open source Git repository, and you will probably want to be with the rest of Git’s followers.

As soon as you have your account on GitHub, start entering your code into it. Fix everything that requires you to write code in the process of work on GitHub. This not only instills a good discipline in handling versions, but also helps you create your own brand.

Note: When exploring the use of git + GitHub, pay special attention to Pull Request (or PRs if you want to be cool).

The brand

Speaking of steepness: own brand is a way to demonstrate to the world what you are capable of. One way (this is currently one of the best ways!) Is to firmly bind GitHub as a proxy for your brand. Almost all employers these days will ask for it one way or another. Therefore, you should strive to have a neat, carefully supervised GitHub account. This is something you can put on your resume and be proud of.

In the following articles, I’ll show you how to create a simple but cool site on GitHub using the Hugo static site generator. It is written in Go, and, perhaps, today is the fastest among analogues. Hugo gathers about 5,000 pages in 6 seconds, which is 75 times the speed of Middleman. But for now, you just need to put your code on GitHub.
Later, when you gain experience, it is worth thinking about having two GitHub accounts. One for storing your own written application, working code, and the other for storing the code that you want to show to others.

So, we summarize the above:

  • learn git
  • Post on GitHub everything you learn
  • use two accounts to store and demonstrate everything you learned
    benefit from it!


Stay up to date with the latest developments in this area, such as GitOps. GitOps takes all the ideas that we have discussed so far to a new level, where everything is done using git, pull requests and deployment pipelines.

Please note that GitOps and similar developments speak about the business side of things, that is, indicate that you are not just using Git, because it is cool and fashionable. You use it to ensure business agility, accelerate innovation and provide faster functions, that is, in order to ultimately make more money!

The sequel will be very soon …

A bit of advertising 🙂

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to your friends, cloud VPS for developers from $ 4.99, A unique analogue of entry-level servers that was invented by us for you: The whole truth about VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps from $ 19 or how to divide the server? (options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

Dell R730xd 2 times cheaper at the Equinix Tier IV data center in Amsterdam? Only here 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV from $ 199 in the Netherlands! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – from $ 99! Read about How to Build Infrastructure Bldg. class c using Dell R730xd E5-2650 v4 servers costing 9,000 euros for a penny?

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *