Lately, I’ve been heads down, hands on keyboard, trying to build a CI/CD pipeline from the ground up. And the more I work on it, the more I realize how strange the DevOps space is. There’s so much information out there, but somehow you walk away feeling like you learned very little. Everyone talks about DevOps, but few people actually explain it in a way that makes sense when you’re just starting to build.
So instead of repeating definitions, I want to talk about DevOps the way I’m experiencing it as a process, a struggle, and honestly, a mindset that only makes sense once you start building things yourself.
This isn’t a “how to become a DevOps engineer” guide. I’m not chasing the title. I’m finishing up a software engineering degree, and this whole CI/CD journey grew naturally out of wanting to understand how things actually work end to end. And yes, before we go any further. I know what you’re thinking. AI. Everyone’s thinking about it right now.
I use AI like everyone else. It’s a great tool. But I think the next few years are going to expose a pretty serious gap: The difference between generating code and understanding the implications of that code. A lot of people will be able to produce things that look correct, but when something breaks, security fails, or systems don’t scale, understanding will matter more than speed.
That’s why I care about foundations. That’s why I care about building systems instead of just outcomes. Alright, AI soapbox over. Let’s talk DevOps.
The Problem With “What Is DevOps?”
If you’ve ever tried to understand DevOps by Googling it, you’ve probably seen the same phrases over and over:
- DevOps is a mindset.
- DevOps is a cultural philosophy.
- DevOps is a way of life.
Cool. That all sounds nice. But at some point, you ask the obvious question: what do you actually do?
And that’s where things get messy.You end up scrolling through blog posts, LinkedIn threads, and “DevOps roadmaps” that list twenty-seven tools you must learn. Then you hit tech Twitter(X), where every post has someone in the comments saying the tool you’re using is outdated, wrong, or “not real DevOps.”
Some of that advice is good. A lot of it comes from experience. But here’s the problem I kept running into: Most of that advice assumes you should start where they are, not where you are. It’s end-game advice presented as a starting point. And when you’re learning, that’s overwhelming. It makes DevOps feel like collecting tools instead of understanding systems.
The Shift That Changed Everything for Me
Every time I hit something I didn’t understand, I started asking myself a simple question: What can I build that forces me to learn this? Instead of trying to memorize definitions, I decided to wrap my final project in a full system. Not just writing code, but designing everything around it.
The idea is simple: What if I don't just stop at “building the app” for my final project, but instead experienced the entire lifecycle?
That meant thinking through:
- writing the application
- pushing code changes
- triggering automated processes
- testing, building, and deploying
- seeing changes move from idea to running software
Not manually. Not once. But repeatedly.
That’s when CI/CD will stop being an abstract concept and became a real thing. CI/CD...continuous integration and continuous deployment, is really about one idea. code shouldn’t sit around. It should move through a system that gives fast feedback and reduces friction between writing and shipping. So I sketched out what I thought my first pipeline should look like. Emphasis on thought!
I already knew people would have opinions. Why not use this tool? Why not do it “the right way”? Why build it like that? That feedback is Ok, but I want you to understand something important: Someone else’s end goal is not your starting point. Your first version is supposed to be rough. It’s supposed to be inefficient. It’s supposed to expose gaps. That’s the point.
This Is Where DevOps Actually Lives
Once you start building, things click in a very different way. You notice manual steps and start asking why they exist.
You wonder why servers are being created one at a time. You start thinking about automation, infrastructure as code, secrets management, and security not because someone told you to, but because your system needs it. That iteration loop is where real learning happens.
- You build.
- You hit friction.
- You adjust.
- You rebuild.
Over and over. That process... That is DevOps. Not a toolchain. Not a buzzword. It’s the act of continuously improving the path between code and production.
People joke about DevOps being a “mindset,” but the more I build, the more I see it as a response to a coordination problem. Manual systems break down fast. Handoffs fail. Nobody knows what stage things are in. Automation isn’t about speed for the sake of speed. It’s about clarity, repeatability, and trust.
Titles Blur When You Start Building
job titles blur once you’re building real systems. System administration, DevOps, DevSecOps, platform engineering, they start overlapping fast. Add security to your pipeline? You’re touching DevSecOps. Automate infrastructure? That’s DevOps. Work on the application itself? That’s software engineering.
When you build from the ground up, those lines stop feeling rigid. And that’s actually a good thing. It makes it easier to pivot. Easier to understand how everything connects. Easier to speak with confidence, not because you memorized terminology, but because you’ve felt the pain. That pain matters.
Why Struggle Is the Point
Building a CI/CD pipeline from scratch is hard. That struggle is what teaches you. Every broken build, every confusing error, every redesign of your diagram is a lesson you can’t get from watching videos alone. It’s the difference between hearing “this is hard” and being able to say, yeah, I know exactly why that’s hard.
Confidence comes from experience and repetition. So when people say something is difficult, I want to test it myself. I want to break it. I want to understand where the complexity lives. Because once you’ve done that, you’re no longer repeating opinions you’re speaking from experience.
Don’t Let the Internet Talk You Out of Building
You don’t have to start complex. Nobody does. It’s okay not to know things. It’s okay to start messy. Complexity will come trust me, but it will come layered on top of things you already understand. The internet loves highlight reels. It loves flexing. It loves making things feel inaccessible. Ignore that. Start simple. Build something small. Break it. Fix it. Repeat. Everything gets easier once you stop overthinking and start doing.
Final Thoughts
If you’re trying to understand DevOps, don’t ask what it is, build something that requires it. Set up a basic environment. Learn what the pieces are. Ask simple questions. Iterate. You don’t need all the answers upfront. You just need to start.
That’s exactly what I’m doing now, building a CI/CD pipeline from the ground up, documenting the process, and learning as I go. Some of that will be structured, some of it will be messy, and all of it will be real.
If you want to follow along with that journey in more detail, I’ll be sharing it step by step. And if you just want deep dives on individual components, those are coming too. As always, stay curious, keep building, and I’ll catch you in the next one.
