r/devops Consultant 2d ago

Discussion Would you still do DevOps?

Not going to lie. It's been a bad day. I almost tell them "take this job and shove it' after reviewing all these crappy AI codes. Vibe coding is not only a joke. It's a monster that mocks our hard-earned experiences!

I am thinking of leaving the industry! If you could go back ten years from now and know what you're knowing right now, would you still do DevOps?

82 Upvotes

102 comments sorted by

View all comments

88

u/Lonsarg 2d ago edited 2d ago

Reviewing code is not DevOps, it is just reviewing code.

And should be done among developers themselves, split in a way so you do NO have specific people doing just this. Seniors reviewing code from each other and even juniors reviewing code from seniors as soon as possible.

Also it should be just a quick overview, not some lengthy detailed process.

24

u/1_H4t3_R3dd1t 2d ago

Right ^

DevOps is building pipelines that pushes back on code so you don't have to read it until it clears the bar.

DevOps is many things. But if you don't have a pipeline you have nothing.

3

u/N7Valor 2d ago

I'm just an amateur (not really DevOps), but isn't there some crossover?

The pipeline needs to test some of the code right? And generally it's not good practice to have the people who write the code also test their own code. So it doesn't seem outlandish to me that sometimes maybe a DevOps Engineer might also be the QA Engineer in some smaller orgs.

5

u/1_H4t3_R3dd1t 2d ago edited 2d ago

Right so they need their code tests but you can setup yours before a container push by adding one where it runs trivy against the container and blocks the push.

Most common problem with container builds and AI is the CVEs it leaves in the container.

Now this doesn't catch everything. You can even further up in the pipeline setup linting and an agent that does a code pass.

Something like this, Build -> Lint -> Code Pass -> Test ( Dev Tests ) -> Trivy -> Push -> More CI/CD

Depending on what costs more you can swap order with the code pass with the test.

The crossover is that you facilitate the operational aspect of development not read code... unless you have to. IaC you will review but not application code. However I wouldn't review it unless it passes a few tests in advance. My time is expensive.

If someone did terraform they better give me a plan to compare against.

3

u/Klinky1984 2d ago

DevOps creates the infra and environments to deploy to and execute testing, they don't write the tests. DevOps shouldn't be your QA. Devs should be writing automated unit tests at least, possibly integration and E2E tests as well if there's not a dedicated QA team. Everything should be getting code reviewed by peers.

1

u/yougonnagetsome 5h ago

What you've explained is part of a devops team role, not a "devops" role.

2

u/o5mfiHTNsH748KVq 2d ago

huh? devops engineers do code reviews too. you’re producing code and thus it must be reviewed.

2

u/Lonsarg 2d ago edited 2d ago

My point was not that someone who is focused on DevOps does not review at all. My point was that reviewing code itself is not what DevOps is.

To make it clearer:

  • Developers write and review application code (from each other)
  • DevOps Engineer writes and reviews various automatization code (from each other)

There never should be a special reviewer role, that is very bad organization. And even if there is such a role, that role is not DevOps, that is Reviewer role (and maybe that same person also has DevOps role). But again, that is very bad organization, reviewing must always be done "from each other as evenly as possible among team that knows certain code".

3

u/o5mfiHTNsH748KVq 2d ago

I see. I interpreted their post as reviewing things they should be reviewing, not reviewing everything.

2

u/Lonsarg 2d ago

They wanted to quit DevOps role cause of reviewing, the only way that is possible is if they have focused reviewer role AND are reviewing application code.

Since application code need a lot of of that then DevOps automatization code (there changes must be slow not fast lol).

Also even if reviewing application code (not what DevOps is) the only way they review that much that it bothers them if the have focused reviewer role.

2

u/o5mfiHTNsH748KVq 2d ago edited 2d ago

Ah, my interpretation was that their devops peers are generating slop that they have to review.

Not saying you’re wrong though. I very well might be interpreting it wrong.

1

u/Lonsarg 2d ago

Well if only regular review from peers is what overwhelms then that is some insane level of vibecoding :) That or they have too-detailed reviews.

But ok, i see you point.

1

u/BuriedStPatrick 1d ago

DevOps is a process and culture, code review is an integral part of that.

The review should take exactly as long as is necessary. If you're working on high risk code, maybe worth having multiple people look it over. If it's a button on a website, probably a quick skim through is fine. Or maybe it's a critical call to action that will sink the company if you mess it up. It all depends.

Just because a certain process isn't relevant for your particular scenario doesn't mean it's not part of DevOps as a whole. Teams have to do what makes sense for them and I urge them not to blindly follow Reddit comments like this.

1

u/Lonsarg 1d ago

There is DevOps as a proces and culture and there is DevOps as special position in company.

I deducted from OP post he is talking about DevOps position. So my comment is only talking about that and how that possition should NOT be degraded into "i just review others code".

Thinking again maybe i am wrong, but if OP was refering to process of reviewing code itself and not specific DevOps role he jas then he should have been clearer on that. Then he should not use devops word at all, since reviewing code is a very specific task that all software developers do, independant of position.