Hi, could you please check/reconsider if Option B is "more correct" than Option D, based on wording of the question?
My argument is that the key sentence is :
"..upgrade to be as fast as possible to LIMIT the time when you will have multiple versions in productions"
i agree that option D, weight 0 and 1 is the FASTEST, but:
1. actually i think it it too fast! as the question use the word "LIMIT" the time you will have two versions (LIMIT>0), it doesn’t say to NOT have at all two versions at the same time, with option D (a part from TTL.. you will have a big bang approach)
2. in production, generally you never want a big bang approach, you always want to check if the new version of the application is behaving differently (better or worse) than the previous, so a minimal amount of time is usually suggested.
3. option B and D will have the same quickly roll back if upgrade fails
Thank you,
Flavio
1 Answers
Hi Flavio,
I think you’re reading too much into the question and have fallen victim to the Practitioner’s Curse. The question asked us to upgrade as fast as possible while limiting two versions. Given this and only this (only what’s in the question), D is the only option that satisfies this best. The question doesn’t add details around our front-end or avoid big-bang. This isn’t a big-bang deployment because usually those are one-way activities…once you cutover, you can’t go back.
–Scott
As well, the answer B is related to A/B testing, not Blue/Green deployment. At least, as per what I’ve seen along this course thus far.
Hi Flavio, I understand your point 1. may be too fast but sometimes front end deployment also demanded some changes at the backend so you’ll want to turn in a row (that your seeing at a bigbang) but both B and D ensure that a rollback is feasible in case something figures wrong once in production. That’s the reason it is not a bigbang, it keeps blue deployment intact for use in case of a rollback is required but you have the ability to upgrade as fast as possible with D.