3 ms·
>You don't know what you don't know. That's the point of regression tests. The sysadmin also doesn't know. Unless he's the one writing the tests (and IME he's
by crdoconnor 10y ago
>You don't know what you don't know.
That's the point of regression tests. The sysadmin also doesn't know. Unless he's the one writing the tests (and IME he's not) or he's painstakingly regression testing everything by hand (trust me, he's not doing that either), making him a gatekeeper for all library upgrades achieves very little except adding bureaucratic friction.
- xorcist 10y agoLook, do you want a gatekeeper or not? For your small little web project you don't need it, and a little downtime probably isn't catastrophic. But as soon as you are under audit rules you need it, and we call this specialized role the admin. When you grow bigger this will likely branch out to a dedicated change manager, at which point you hopefully have other specialized roles for security as other things as well. I understand this does not make sense when you are not more people than can fit around a table, but as you grow you will feel the need for more and more specialized roles to fit the changing requirements. The first specialized role is probably the sysadmin (devops, reliability engineer, whatever you call it) and he or she should preferrably be the one on the team with the most knowledge of how things work "under the hood" because that person is the one that can save you when things go haywire. Unless you trust this person to be more knowledgable than you are in those areas, as they rightfully should be, you're going to have a problem.
- crdoconnor 10y ago>Look, do you want a gatekeeper or not? No, ideally not - that's the idea behind https://en.wikipedia.org/wiki/Continuous_delivery https://en.wikipedia.org/wiki/Continuous_delivery Where gatekeepers are required (because regression testing is not yet fully trusted enough for continuous delivery), QA should be the gatekeeper, not sysadmins. >For your small little web project My comments are based upon working on projects with a turnover of > ~1-1.5 million USD / day. >But as soon as you are under audit rules you need it, and we call this specialized role the admin. When you grow bigger this will likely branch out to a dedicated change manager Every time I've worked with somebody whose role was "change manager" this role was introduced: * As a response to repeated downtime in the past caused by some kind of idiocy. * They were required to "sign off" on releases purely as an added bureaucratic step to cover some manager's ass. * They never once prevented or caught a production issue. * They always slowed down releases. >The first specialized role is probably the sysadmin (devops, reliability engineer, whatever you call it) and he or she should preferrably be the one on the team with the most knowledge of how things work "under the hood" because that person is the one that can save you when things go haywire. Unless you trust this person to be more knowledgable than you are in those areas Ironically the whole idea behind devops (which I fully agree with) is that it should not be a specialized role - developers and ops teams should be blended. This is precisely because if the two teams are separate and one throws code over the wall to the other then things will go wrong. Then a manager will insist on a gatekeeper.