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.
No, ideally not - that's the idea behind 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.