> an engineer is designated as the deploy commander in charge of rolling out the new build to production.
When I last did ops we pushed the automation and alerting hard, so the idea of someone being formally assigned to a deployment is interesting. This sounds like they have a ton of manual or semi scripted steps. At some point, removing the dedicated deployment commander and relying on alerting is helpful, although preference of where that point is can be debated.
i think the notion of a commander is a very interesting people-ops strategy.
it keeps the little element of subjectivity in things like - when do you kick off a build, how long do you run the integration/release process, etc
You do lead with automation, but the introduction of human subjectivity is a low-overhead way to still have flexibility.
More likely, they have a few bugs here and there in the deployment tools that require human supervision and intervention, and they don't have the resources right now to fix them and to make it more reliable.
There is no need for flexibility in a repetitive process, unless there are bugged edge cases
When I last did ops we pushed the automation and alerting hard, so the idea of someone being formally assigned to a deployment is interesting. This sounds like they have a ton of manual or semi scripted steps. At some point, removing the dedicated deployment commander and relying on alerting is helpful, although preference of where that point is can be debated.