4 ms·
> I can't imagine that responsibility for MY code in production (and delivery of the said code to production) lies on a different team/department that are poss
by porpoisemonkey 7y ago
> I can't imagine that responsibility for MY code in production (and delivery of the said code to production) lies on a different team/department that are possibly not even on the same floor/building I'm at.
I recently did some interviews with our devs to find out what features we could add to our platform that would provide them with value. The result was interesting and I found that people typically fall into one of two camps:
1) I want to know everything about my deployed service and have tools that alert me and allow me to intervene, or
2) I don't want to know anything about the deployed service runtime and expect operations to handle my issues and alert me when there's a problem.
It sounds like you might be in the former. =)
- iliketocomplain 7y agoThat actually is interesting, thanks.
- rinchik 7y agoThe initial intention (of DevOps) was to eliminate these discrepancies by eliminating Ops department all together. DevOps doesn't necessarily mean devs doing ops, but it means devs and people curios about ops sit together, as one team, as one department, right next to each other. This setup improves practically every aspect of the product development, support, and delivery, as well as collaboration, communication, and response times. Initial intention aside, it feels that there is a general consensus that VAST majority of the companies that have `devOps` in the job description somewhere are cargo culting and have no clue what they are doing. If you slap `Dev` prefix to your Ops department your job postings will look "trendy" but nothing else will actually change. DevOps is a culture, not a team or department.
- ek750 7y agoSounds like how companies or teams cargo-cult “Agile” and have no idea what it is or why.