An internal low-risk municipal wiki can accept brief downtime, but tax-filing-week services cannot. How should deployment strategies differ?
Select an answer to reveal the explanation.
Short Explanation
Match the parachute to the jump. A quiet internal wiki can stomach an all-at-once bump; tax week needs rolling or blue/green so citizens keep filing while you ship.
Full Explanation
Deployment strategy should follow business risk, not a single dogma for every municipal system across the portfolio. An internal low-risk wiki that can tolerate brief downtime may reasonably use all-at-once deploys for simplicity, while tax-filing-week services need rolling or blue/green strategies that preserve capacity and enable safer rollback when filings cannot wait. Forcing all-at-once on tax systems while reserving blue/green for the wiki inverts risk priorities during the city's most sensitive revenue window. Freezing every municipal system from deploying for an entire calendar year blocks security patches and urgent citizen-facing fixes. Using the same untested all-at-once cutover for both wiki and tax APIs ignores differentiated availability needs across departments. Exam caveat: even low-risk all-at-once deploys still need a tested prior artifact so a bad wiki release does not become a prolonged helpdesk incident. Operational check: classify applications by allowed downtime, map each class to a deployment strategy in the pipeline templates, rehearse a tax-path rolling or blue/green failure, and confirm rollback still meets filing-week RTO with synthetic payment or filing checks.