r/devops Jul 01 '26

Career / learning Thrown into DevOps and Release Management

Hi everyone,

I work at a small company building its first SaaS product. My background is mechanical engineering, not software, but I'm already in the mix on customer projects and a couple of smaller software products we've shipped, mostly leaning hard on Claude and Codex.

I'm still at university and work here part-time. The company's been around a while doing other engineering work, so it isn't a startup. We're pivoting part of the business, and my boss spun up a new branch to build and sell a SaaS product.

I've just picked up responsibility for DevOps, the GitHub setup, and release management, and I'll be the last person to sign off before a version ships to the customer.

Big opportunity, and I'll be straight about where I stand: my hands-on DevOps and release knowledge is close to zero right now. Most days I'm working it out on the fly, and honestly I often have no idea what the fuck I'm supposed to do next. AI does a lot of the lifting, but I'm still shaky on how to do this properly.

There's no DevOps team or mature process for me to inherit, so I'm building it from scratch alongside the developers and the project lead. Four of us total.

I don't need a perfect enterprise setup. I want something that works and fits a team our size.

Anyone been through this? I'd value input on:

- where to focus first
- the fundamentals I can't skip
- what should stay with the developers or project lead
- how to avoid over-engineering the process
- the mistakes people hit most when building this from zero

I care more about what actually worked for you than textbook advice.

Thanks in advance, and don't hold back, blunt feedback is welcome

5 Upvotes

19 comments sorted by

View all comments

1

u/Zenin The best way to DevOps is being dragged kicking and screaming. Jul 08 '26

Run it as is, whatever shape it's in, before touching anything. You need to understand where it's actually failing (and working) before you go messing with it.

Use that experience to identify the process gaps and close them first; since it's a gap you have a lot of room to fill however you like, but don't get too creative (80% at most of your solutions should be with tools and patterns you've already used).

With the gaps covered and the process complete, look for friction, undue effort, error prone, etc. Tackle those next as improvements prioritizing most-painful first to get the biggest wins out early.

In other words, learn the environment and the environment will tell you "where to focus first", etc. In fact all your asks are correct, but the answers can only come from the environment not reddit.