3 ms·
The extent of devops for your developers should be: 1. Push code to an automated pipeline 2. I understand that the automated pipeline may need input from me i
by brightball 4y ago
The extent of devops for your developers should be:
1. Push code to an automated pipeline
2. I understand that the automated pipeline may need input from me in order to run successfully.
Beyond that, you need other people building the "platform" that they're deploying to (for the most part). Probably the ideal example here is Heroku.
Your devs shouldn't be required to do all of the actual ops stuff. They need access to an ops platform.
- ghaff 4y agoTo grossly oversimplify, there are essentially two views of DevOps. 1.) What's probably the traditional view which is breaking down the walls between devs and ops, developers carrying pagers, etc. I.e. at least in an idealized world, there are no devs and ops--only DevOps. 2.) As you suggest (and which probably more closely matches how "DevOps" works especially in larger organizations), an internal (or external) operations team provides a platform that developers can use. Developers are still going to be exposed to some operational details, but a lot of them are abstracted away.
- Izkata 4y ago3) The way I first heard it described years ago, bringing developer practices into ops: version control, testing, code reviews, continuous integration, etc
- kazen44 4y ago> bringing developer practices into ops: version control, testing, code reviews, continuous integration, etc In my opinion, this last subset just doesn't work well for a lot of branches of operations. Sure, it might work if you run stuff in AWS and have an operations team managing that, But what if your team is responsible for things like Storage Arrays, networking equipment? Doing continious integration and code review on some of these is hard if not impossible
- dilyevsky 4y agoHighly dependent on the product. Anything infrastructure related you’ll have a really bad time with that model
- wschoenberger 4y agoThe article has a solid solution ;)
- tremon 4y agoI expect my developers to troubleshoot a failing pipeline too. The pipeline is part of the "ops platform" they're expected to work with.
- tetha 4y ago> Your devs shouldn't be required to do all of the actual ops stuff. They need access to an ops platform. This becomes a lot more apparent once you're dealing with B2B customers and their nonfunctional requirements. We've had situations in-house when devs built some simple microservice to handle some connection to a customers BI/DWH system - it's just 2 days of spring boot chugging to wrangle APIs around without state, nothing bad. But then, the customer started blasting that team with SLAs, backup questions like RTO, RPO, retention, regulation adherence of retention, the whole stack of IT security down to the physical access control.. That poor PO was caught just like a deer in the headlights. This is some operational responsibility we're taking over for our dev-teams. We're providing the persistence, and this includes a defined backup and recovery strategy, a security strategy and such. And this also includes experience in dealing with these insane questionaires, and correctly pricing absurd requirements for custom backup solutions. And in fact, "we will have to schedule a discussion with ops about this" has ended quite a few of these requirements with "oh.. it's not that important". Intimidation with long job titles and appeals to external authority do work.