4 ms·
The thing i have come to dislike is that in both companies i work for it lead to strange working relationships between ops/eng. anything that breaks in the depl
by medellin 3y ago
The thing i have come to dislike is that in both companies i work for it lead to strange working relationships between ops/eng. anything that breaks in the deploy pipeline is now “the devops team problem” and they normally act like it’s also your fault. In the past this has meant people messaging me saying they are blocked because their dockerfile fails in CI. Then you walk through it with them and it’s also broken locally and it comes down to them pinning to something like latest tag and the image “shocker” changed. But now you are fixing it and after you go remind everyone that you should pin your image to as strict as possible image tag. But no one cares because they can move fast and break things and when it does blame it on CI and now it’s not their problem.
Anyway this is just one tiny example but the same underlying thing starts happening in all parts of the development cycle. “My deploy doesn’t work” … well your program has an error and crashes on startup but looking at the logs would be too much work. Let’s just say we are blocked and log off.
As you can see this is a culture issue but it seems to be common when you have a devops team. And even more common when management (read senior management and up) think that developers “should just be developing”.
Anyway thats my rant.
- anotherhue 3y agoI have seen infra/devops scapegoated too much. Half the time the developers in question won't even read the error output before raising a ticket. The only solution I see is to enforce commit checks before hitting shared environments, but that comes with its own set of complaints.
- tstrimple 3y ago> Half the time the developers in question won't even read the error output before raising a ticket. If they had no DevOps team to raise a ticket with, and it had to get done they would find some way to figure it out if they had the ability to modify and initiate their own pipelines. The reason I like "you build it you run it" is I feel like I have far more control over my own destiny. You're not having to negotiate and coordinate with a separate team through some ticketing system. Far less wasted back and forth and miscommunication. If that means you have to expand one of your teams with an additional DevOps person to foster understanding of the tooling on a team who hasn't done it before that's fine. But don't make them the DevOps person. Their goal is to enable the rest of the team to pick up these skills. Their goal should be to transition into a normal contributing member of the team working on product development because the team no longer has a need for a DevOps person.