The build and deploy engineer is a role in IT/infrastructure/devops teams of organizations that is responsible for deploying a set of applications using CI/CD pipelines. Usually, they use the pipelines, tools and processes created by DevOps engineers, consultants or practitioners. They tweak things with tools like Ansible, Jenkins, Git, Maven, etc. here and there a bit.

Are you one such build and deploy engineer looking to transition your career into DevOps engineering? Here’s a path you could follow:

Phase 1: Linux And Programming

• Learn Linux well. Take one or two courses. Or watch a bunch of videos and read articles. Whatever mode of training works best for you. For a list of Linux topics, take a look at the course and certification contents of LFCS and LFCE. Going through a course is the first step. That is not the end. The best thing that can happen while learning is, someone paying you to apply what you learn. Ideally, if your current job is directly related to what you are learning, look for opportunities to implement the newly learned concepts. Whenever you learn new things, try to implement them at work. Ask your supervisor for any opportunities to practice your newly acquired skills. Even better if you find the opportunities yourself and then ask your supervisor if they agree to your proposals. If not, practice what you learned on your side projects. One of the mistakes novice learners make is to watch a video tutorial and assume that they have learned the topic. Watching the video or reading a text tutorial is the first step. You learn the topic really well when you implement them in your project. Without gaining practical experience do not assume you have learned the topic. Use mastery based learning. Install Linux on your laptop. Discover applications and workflow and start getting comfortable using Linux as your primary OS.
• Learn virtualization. Use virtual machines to play with Linux and related technologies. For example, install WordPress on a virtual machine and play with it. You can learn a lot by experimenting locally on your laptop. You don’t need the cloud or paid hosting services to learn a vast majority of Linux and infrastructure topics.
• Automation. Start automating using shell scripting. This is the common language system administrators and DevOps engineers and consultants speak(read and write).
• Take the next step in automation. Learn Ansible. As you learn and keep practicing Ansible, you will appreciate how Ansible takes the pain out of shell scripting. Ansible opens the doors to higher level scripting and automation. Start converting your shell scripts to Ansible playbooks and roles.
• Learn a programming language. Being a system administrator or a DevOps engineer involves writing scripts and programs in languages other than shell/BASH. Pick any popular language such as Python, Go, JavaScript, etc. To hone your programming skills, write your own application. It could be anything such as a CMS, blog, e-commerce, game, business application or whatever you think is cool. Don’t be afraid to learn related technologies. If you are writing a web application, you will have to learn HTML, CSS and JavaScript. You don’t need the depth in these related technologies at first. Just learn whatever minimum is required to accomplish your goals. Start with the 101 tutorials and start implementing what you learn in your project. In some ways, a DevOps engineer is an SDLC guru. As a DevOps engineer you will work with software development teams frequently. In addition to knowing the tricks of your trade, you also have to have some insights into how the software development teams are solving problems. It helps to know the tools, technologies and processes the software development teams use. Being a developer yourself, you can easily put yourself in their shoes to understand their perspective. As you tread along the DevOps engineering journey, you will find your writing programs in domain specific languages. Ansible uses YAML. Terraform uses HCL. There are some popular web templating languages such as Jinja2 and Go templating. At some point you will have to write programs/scripts in such domain specific languages. Such domain specific languages do not provide good developer experience. They are meant to solve a small set of problems. If you learn a general purpose programming language such as Python or Go, you will do well in such domain specific languages later. It’s all about getting the fundamentals right.
• SQL basics: Learn basic SQL. Install MySQL, MariaDB or PostgreSQL for your project. Create some tables and columns. Learn SELECT, INSERT, UPDATE and DELETE queries. Learn some clauses. Learn other SQL concepts as and when the need arises. Learn to make backups and restore backups of your database. Depending on the lens you wear you could view software engineering as a field that is all about data. Learning a few data store technologies can go a long way in DevOps. Relational databases is a key technology in data storage and retrieval well suited for many common types of applications.
• Learn Git. Start with the basics. Learn to clone, commit, push, pull and branch. The rest, you can learn when the need arises. At a later point you can learn cool tricks such as rebasing, squashing, reverting, etc. These advanced Git topics are not needed on day one. Especially on a small solo beginner project.

Phase 2: Networking And Web

• Buy a domain name. It costs money, about $10 to $12 per year. Unfortunately, DNS is a key networking protocol and you really need to learn and play with DNS to be a successful DevOps practitioner.
• Don’t use proprietary cloud services yet. You are not ready for the cloud at this point. Why am I saying you are ready for the cloud at this point? The cloud is infrastructure packaged in a convenient API. The foundations of the cloud infrastructure are compute, network and storage. Without understanding the basics of these foundational elements of infrastructure, you will face difficulty in every step of cloud engineering.
• Run your own DNS server for your domain. Use a VPS provider such as Hetzner or Linode to host your own DNS server. You don’t have to maintain the DNS servers forever. I recommend running your own DNS servers for at least a year. After you understand the technology really well, then you can take down your DNS servers and use a hosted service to free yourself from the maintenance burden.
• Learn HTTP and get familiar with a web server. Take your pick: Apache, Nginx or whatever suits your needs. Learn to use HTTPS and X509 certificates. Explore reverse proxies and name based virtual hosting. Add more buzzwords to your toolbox. This time add SNI :)
• Learn some networking. CIDRs, subnets, firewall, routing, etc. CISCO certifications maybe attractive, but not the only option. Grow With Google has a nice and free introductory course on networking which I recommend to beginners.
• Learn some storage. Partitioning and volume management. Mounting, unmounting, resizing etc. Tinker with network based storage services such as NFS.

Phase 3: Cloud And Automation

• Cloud. At this point you are ready to learn cloud technologies. Take your pick: AWS, GCP or Azure or anything else. Learn the basics. Deploy your app to the cloud.
• Terraform. Use Terraform to orchestrate cloud resources.

Phase 4: Containers

• Containers. Docker is the most popular tool out there. There’s also Podman. Picker whatever and run with it.
• Learn the Kubernetes basics. The Kubernetes documentation is awesome and also provides access to Kubernetes clusters in the browser. Take advantage of the free resources at your disposal.

Resume Dos And Donts

• Be honest and write only what you know. Don’t just throw in a bunch of buzzwords and tool names. List what you have actually done in your projects. Being a build and deploy engineer exposes you to few technical terms and names such as Ansible, Terraform, Docker, Kubernetes, Linux, cloud, etc. Just because you have had a glimpse of these tools does not mean you know how to use them from scratch. This is one the problems I have seen among many wannabe DevOps engineers. The claims are tall. The interviews do not last longer than ten minutes with such candidates. Knowingly or unknowingly, don’t come across as naive or fake. If you claim to know a lot of things and fail to answer basic questions, the interviewer will perceive you as either naive or fake. They might think you are naive because they might think you don’t know what you don’t know. In other words, they might think that you are not even aware of the fact that you can’t actually use the said tools from scratch independently. They might think that you are a fake because they might think that knowingly you are claiming to be an expert in the said topics when you actually have barely scratched the surface. This is a waste of time for you and the interviewer. It may also affect your morale negatively because of repeated rejections. In a nutshell, beware of the cognitive bias called the Dunning-Kruger effect.
• List your side projects. Better if you post links to your Git repositories. This is your chance to let the interviewer know about your interests and expertise. Try to make your side-projects stand out in terms of quality. Embrace best-practices and try to implement them as much as possible. Pay attention to security. Beginners often have a tendency to discard security in software and infrastructure. A typical enterprise company spends a lot of money and resources to make their software and infrastructure secure. Dissing security will probably bury your resume in the crowd. On the other hand, if you pay attention to security and try to implement security best-practices, there’s a good chance your resume and candidature will stand out.

Bonus Tips

• Improve your soft skills. Especially people and communication skills. Improve your reading comprehension simply by reading more. DevOps engineering involves reading a lot of documentation. Often, you will come across the phrase: RTFM. Start practicing reading articles and documentation pages. To generally improve your reading skills try reading novels. Start small and aim to read books with a lot of pages. Acquiring reading comprehension skills cannot be done in a short period of time. Just think of it as a path to improve your cognitive skills in the long run.
• Improve work ethic. Don’t be in a position where you have to be micro-managed. Don’t make your supervisor come back and follow-up with you. Instead proactively, provide updates and feedback to your team and supervisor. If something takes a long time, tell the team that you are working on it and provide frequent updates. If you need help, ask. Try to avoid asking help for things you can easily figure out on your own. For example, if you want to find a command’s parameter options, instead of asking a colleague, search the web and find it out yourself. If you can’t find information on your own, then ask for help. Do some basic work to attempt to resolve the situation yourself before asking for help.
• Quality of work is important. You just can’t ignore it. Don’t call experiments as done projects. It is one thing to make a proof of concept. It is another thing to finish the project with good quality. It takes a few iterations to improve the quality of work. Don’t call iteration number one as the end. Remember, step one is the starting point of a great product or project.
• Stop guess work. Start evidence based work. When troubleshooting or diagnosing an issue, gather evidence from logs, traces, errors, etc. Make isolated experiments to prove the hypothesis. Ask for review from team mates for non-trivial work.
• With dedication and discipline you can learn any programming language or technology. Don’t be afraid of any technology buzzwords. You don’t need to go to an ivy league college or university to learn technology. You can find free and cheap paid resources to learn almost anything on the Internet. You can get far ahead by smartly using the computer, Internet and your time.
• You can get help for free. Stuck with something? Got a question? You can find community forums with kind people who are willing to help you. Every technology or project has approachable community forums. Find them, get help and also help others if you can. Before asking for help, ask yourself: can I find the information on my own? Maybe a couple Google searches or reading the documentation? This line of thinking will help you contribute to the team or organization independently. Make it a habit and turn it into a useful lifelong skill: information lookup.
• Keep on learning. Embrace the philosophy of life-long learning.
• Find mentors. A mentor can guide with your career path and help optimize the learning journey. It might be easier than you think to find a mentor. Try to find some leaders in the communities: Github, LindkedIn, Twitter, etc. Reach out to them and ask them whether they can mentor to you become a good DevOps engineer.

What is 101? Beginner tutorials in computer science are often called as 101 tutorials. In contrast to 101, 401 indicates advanced topic tutorials.

You might be wondering how long does it take to complete this path? It’s a subjective question and depends on various factors such as your background, available free time, motivation, environment, etc. If you put in something like two hours per day and more hours during weekends, you can probably progress a lot in six months to one year. At this point you will be in a better position to apply for DevOps engineering jobs. Of course you might be able to do it faster or slower. It’s not a one size fits all estimate.

Happy learning!

Tech Chorus References

• Learning Linux For Devops

Let’s discuss this topic on the Twitter thread.

• devops
• career