Add guidance on big-bang releases.

[adunkman]

We like to advocate for slow rollout releases over big-bang releases. That’s probably something we’d like to document somewhere, but is out of scope for this issue.

Instead, we often find ourselves working in projects which, for reasons we cannot control and against our advice, are scheduled for a big-bang release.

I think we’ve learned some things which we should pass on about this release strategy.

[afeld]

Shout-out to Hello, Production.

[ryanwoldatwork]

https://dzone.com/articles/monolith-to-microservices-using-the-strangler-patt

• about de-composing large running applications as part of modernizing them

[adunkman]

Just wanted to loop back to the original issue:

We like to advocate for slow rollout releases … [it] is out of scope for this issue.

Strategies that reduced stress and helped the US Tax Court with their big-bang release:

• Release to different user groups at different times — namely, internal users first, then the public. This allowed customer support and bug fixing to focus on specific user groups and tasks. The US Tax Court separated the releases by a week.
• Give yourself a lot of time — the US Tax Court set the expectation that the old system would go offline about 2 months before promising the new system would come online. This gave the team plenty of time to adjust as critical issues were discovered, and required contingency planning on alternative strategies to keep the court functioning without the software system, which reduced the overall stress of the release (there was a plan B, despite it being painful).
• Develop training strategies in advance — give a test environment to critical user groups to play with, record training videos, document common tasks — overall, figure out how to make users familiar with the system before they are required to use it suddenly.
• Practice data migration efforts — run the migration process from the legacy system to the new system regularly until it is well practiced. On the Tax Court project, we ran it in the neighborhood of 15 times in the months leading up to release.
• Prepare templated customer support responses — launches often have expected support requests, like "this is great but why didn’t it do Y" or "this thing is broken" or "I can’t find out how to Z". We can work with the people responding to requests and the product owner to develop a set of templates or core phrases which can help develop a better user experience.

[Sgtpluck]

@adunkman notes taken during the guild meeting are here.

@mheadd also identified a need (that is documented in #232) for identifying factors that encourage big bang releases and coming up with strong ways to mitigate them -- we started a spreadsheet for that info.

Were you interested in writing this stuff up? Did you want help with that?

[adunkman]

I am interested in writing it up, and it’s a bit down my list. I’ll keep this issue updated and likely knock it out in one go — so if there isn’t a linked PR here, I haven’t started it yet.

If anyone else beats me to it, go for it! :)

[Sgtpluck]

Closed with #257