How I Would Set Up DevOps for a Team, and What I Would Do First

At Vendavo, we moved our services off of virtual machines and onto App Services and Kubernetes. A move like that is about a lot more than where the code runs. It changes how you build, test, ship, and support everything. The new platform is only half the work. The other half is the process around it.

That experience shaped how I think about DevOps. Most of the hard parts are not technical. They are about picking the right order, getting teams to trust the process, and not trying to fix everything at once.

Here is how I would set up DevOps for a team, in the order I would do it.

1. Start by Listening

Before picking tools, I would spend time finding out what actually slows the team down. Is it slow builds? Scary deploys? Waiting on another team for infrastructure? Not knowing when something breaks?

Every team has a different bottleneck. If you show up with a full plan on day one, you will probably solve problems nobody has and miss the one everyone complains about. Fixing the biggest pain first also earns you trust, which you will need for everything after.

2. Put Everything in Source Control

This sounds basic, but it is the foundation for everything else. App code, pipeline definitions, infrastructure, and config all live in Git, and every change goes through a pull request.

That gives you three things right away:

• A history of what changed, when, and who approved it.
• A review step where someone else looks at the change before it goes out.
• One place to look when something breaks.

If a change can only be made by clicking around in a portal, it should be on the list to fix.

3. Make CI Fast and Trusted

Every pull request should automatically build the code, run the tests, and check the infrastructure changes. The goal is simple: a developer should know within a few minutes if their change is safe to merge.

Two things matter more than the tools you pick:

• Speed. If CI takes 40 minutes, people stop waiting for it and start working around it.
• Trust. Flaky tests are worse than no tests. If a failed build usually means "just rerun it," people learn to ignore red builds, including the real ones.

I would rather have a small set of fast, reliable checks than a huge suite nobody believes.

4. Make Deploys Boring

A deploy should be a non-event. The way to get there is to make every deploy work the same way:

• No deploying from laptops. Everything goes through the pipeline, so every deploy is logged and repeatable.
• Same pipeline for every environment. Dev, staging, and prod use the same steps, so prod is never the first time a process runs.
• Approvals only where they matter. A manual approval before prod makes sense. Approvals on every dev deploy just slow people down and teach them to click "approve" without looking.
• Easy rollbacks. Knowing you can undo a bad release quickly makes everyone less afraid to ship.

5. Bring Infrastructure Into Code, One Piece at a Time

Infrastructure as code is a must, but I would not try to rewrite everything in Terraform in one big project. That is how you end up six months in with nothing finished.

Instead, I would start with whatever changes the most or breaks the most, then expand from there. New resources get built in code from day one. Old resources get moved over when someone needs to touch them anyway.

I wrote more about how I approach this in learning and onboarding engineers to Terraform and when to create Terraform modules.

6. Connect Monitoring to Deploys

Shipping faster only helps if you can tell when a release made things worse. Every service should have basic health signals: is it up, is it fast, is it throwing errors.

The key is tying those signals back to deploys. When error rates jump, the first question is always "what changed?" If your dashboards show when each deploy happened, you can answer that in seconds instead of digging through chat history.

Once that is in place, SLOs give the team a shared way to decide when to slow down and focus on reliability. I covered that in my post on SLIs, SLOs, and error budgets.

7. Make It Self-Service

The last step is making sure the whole setup does not depend on one person. If every new service, pipeline, or environment needs a ticket to the DevOps team, you have just built a new bottleneck.

Good templates, clear docs, and sensible defaults let teams set up a new service on their own. The platform team reviews and improves the templates instead of doing every setup by hand. I go deeper on this in my post on collective ownership.

What I Would Leave for Later

Knowing what to skip matters just as much. Early on, I would hold off on:

• A custom internal developer portal. Templates and good docs get you most of the value for a fraction of the work.
• Complicated branching strategies. Short-lived branches merged often into main are easier to understand and cause fewer painful merges.
• Chasing a perfect setup. A simple pipeline that every team uses beats a perfect one that only one team adopted.

Wrapping Up

Let's be honest, none of these steps are new ideas. What makes DevOps work is the order you do them in and getting people to actually use them. Start with what hurts the most, make the safe path the easy path, and build trust one boring deploy at a time.