|
|
|
|
|
|
by hello_moto
703 days ago
|
|
|
If you refer Canary deployment as the vendor's internal deployment? I definitely agree. What I find it hard is those in Software that suggested to roll it to a few customers first because this isn't cloud deployment doing A/B test when it comes to Virus Definition. Customers must know what's going on when it comes to virus definition and the implication of them whether they're being part of the rollout group or not. |
|
|
No, I’m talking about external deployment to customers. They clearly also had a massive failure in their internal processes too, since a bug this egregious should never make it to the release stage. But that is not what I am talking about right now.
> What I find it hard is those in Software that suggested to roll it to a few customers first because this isn't cloud deployment doing A/B test when it comes to Virus Definition.
I don’t care what you’re releasing to customers— application binary, configuration change, virus definition, etc, if it has the chance of doing this much damage it must be deployed in a controlled, phased way. You cannot 100% one-shot deploy any change that has the potential to boot-loop a massive amount of systems like this. This current process is unacceptable.
> Customers must know what's going on when it comes to virus definition and the implication of them whether they're being part of the rollout group or not.
Who says they don’t have to know? Telling your customers that an update is planned and giving them a time window for their update seems reasonable to me.