I'm a QA Engineer in the gaming industry with about nine years of experience, and I'm seriously considering moving into DevOps. I understand the software development and testing lifecycles and have participated in features from initial discussions through development, testing, and production release. I've used Jenkins for builds and deployments, Git mainly for creating pull requests, Grafana for investigating logs and application issues, and AWS Systems Manager to access servers, tail logs, and update server-side configuration. I've also recently started learning Python and Java.
I have a good relationship with my company's DevOps team and manager, so an internal transition may be possible once I'm better prepared. I know I still have a lot to learn and would like a realistic, practical roadmap rather than shortcuts.
What should I prioritize first among Linux, networking, Git, Bash or Python, Docker, Kubernetes, CI/CD, Terraform, and AWS? Which beginner-friendly resources or project ideas would be useful? How much programming should I learn, and how can I make the most of my existing QA, release, deployment, monitoring, and troubleshooting experience? Is moving internally into a DevOps role reasonable before I meet every requirement of a typical job posting? If you were in my position, what would you learn over the next six to twelve months, and in what order?
1 Answer
The biggest shift is moving from executing established procedures to understanding and improving the systems behind them. Instead of only running a deployment or checking a dashboard, aim to learn how to design the pipeline, automate the process, define the infrastructure, and create the playbooks that other people can use.
A sensible order would be Linux and Bash fundamentals, networking basics, Git workflows, and then CI/CD. After that, build small projects with Docker, cloud services, infrastructure as code such as Terraform, and finally Kubernetes. Python is useful for automation, but you do not need to become a full-time software developer before making the transition. Your experience with testing, release coordination, Jenkins, production troubleshooting, and understanding failure cases is already highly relevant. An internal move is also a strong approach because your existing product knowledge and relationships can make it easier to learn through real tasks.
That makes sense. I’ll focus first on the mindset change and on learning to automate and improve the process rather than just carrying out existing steps. I’ll also look into the fundamentals before jumping straight into Kubernetes or advanced cloud topics.