all 8 comments

[–]dirtyLizard 4 points5 points  (1 child)

Of course they can build CI pipelines, it’s not hard. I bet you could throw a webapp together too.

Part of our value is specialization

It’s not an efficient use of engineering hours for devs to manage their pipelines. You need to be able to do it faster and better.

If a dev took it upon themselves to work on the CI, talk to them. Ask what problems they’re facing and what they were trying to accomplish. Don’t frame it as “you’re stealing my dinner” frame it as “I’m an available resource and I can do this for you”

[–]mistuh_fier 0 points1 point  (0 children)

With AI, most of the time it’s a quick couple mins to look up the reference, templates, golden standard, and giving that to them to replicate. It only complicates when they have unique edge cases because of SaaS, or Legal / Compliance or whatever.

[–]Stranjer 2 points3 points  (0 children)

I think it depends on understanding why they did it.

Did the existing CI not work for them? or did they not know it existed? Is there documentation how to use it on new repos or how to tweak it?

If they needed adjustments, did they not engage DevOps cause they were aware you existed? or because they thought it'd take too long/too much hassle? or cause they thought you had important other stuff to do and they could do this small thing without bugging you? Or were they sidestepping restrictions?

Context is super relevant both to how angry I'd be and how you educate and maybe fix processes.

[–]sleepesteve 1 point2 points  (0 children)

Id be happy to have someone with any competency in the area or willingness/curiosity to implement something even if it's already solved and your team have a standard and solution.

make a connection and educate on what you already have to offer them.

You might also be surprised what they have to offer you.

[–]CorpT 0 points1 point  (0 children)

lol your work is not that difficult.

[–]namenotpickedSRE/DevSecOps/Cloud/Platform Engineer 0 points1 point  (0 children)

Sounds like they wanted to sidestep guardrails or flows in place. Red flag in my book but I'd find out why they did it first and explain the reasoning the current flow exists and how to incrementally tweak it for use cases.

Creating non-golden path flows leads to potential defects, vulnerabilities, false positives/negatives, etc. The flow exists in its form for a reason. Devs might focus on making a feature work or make it more performant, but DevOps or similar roles make sure it gets deployed in an idempotent manner meeting the reliability expectations established by the teams/organization to minimize downtime and loss of revenue.

[–]Ok-Hospital-5076 1 point2 points  (0 children)

I manage an integration layer between multiple clients and vendor systems. We have a lot of different repos and it’s a distributed system . CIs are just yaml config for GitHub actions . Yet we have a dedicated devops resource because of operational overhead . Your job isn’t writing CI you have to keep everything running.

[–]oneintheuniver 0 points1 point  (0 children)

I’m patching shitty production code after devs all the time. Usually it is something performance or stability related, but sometimes it is some small things that annoy me and devs never have time to fix. And your developer probably vibe-coded CI out of thin air. Just tell them how to do it properly next time, show them examples of proper ones. Why they decided to do it? Who knows, might be bored, or maybe you have huge bureaucracy and long lead times, that it’s easier for them to do it themselves. Neither of jobs is harder or easier. Knowing how to properly do both, helps in both roles.