department-of-veterans-affairs / va.gov-cms

Editor-centered management for Veteran-centered content.
https://prod.cms.va.gov
GNU General Public License v2.0
96 stars 69 forks source link

DUW: Launch plan #17084

Open jilladams opened 7 months ago

jilladams commented 7 months ago

Pre-launch

Go / No Go

Launch

Day After Launch Day

Post Launch

FranECross commented 7 months ago

@randimays No rush, but will you please take a look at the Task list above, especially items talking about the new/old urls? One item I'm specifically wondering about is "when it's time to release, remove content-build flag; /new-url goes to production." Aren't we only using the new url on Staging to keep the code from deploying to prod, and then when we release, we'll actually release to the existing/old url? Thanks in advance!

randimays commented 7 months ago

@FranECross I suggested this launch plan because Dave wants a way to feature flag (or otherwise quickly switch back to the old DUW) if something goes wrong at launch. The only way to do that is to build two separate applications so we can toggle the config and point /discharge-upgrade-instructions to whatever application code we want. If we do have to revert our launch, it would still require merges/deploys and multiple OOB requests, but it's the best we can do.

Other approaches we ruled out:

  1. Make changes to the old code in place (overwrite it), merge code per ticket: those changes will roll to production within 24 hours and we'll lose the current production version of DUW before we're ready
  2. Make changes to the old code in place (overwrite it), BUT don't merge; instead use a feature branch / Tugboat: anyone without SOCKS access cannot review the app (thinking mostly of CAIA here)
FranECross commented 7 months ago

@randimays Thanks so much for the clarification! I really appreciate it.

jilladams commented 7 months ago

Mikki weighed in on slack thread: https://dsva.slack.com/archives/C52CL1PKQ/p1706899302700859?thread_ts=1705605019.314219&cid=C52CL1PKQ

Can we have the new version utilize the same root URL, but have it render at /introduction for the first page, and all subsequent pages would have new slugs as well? This way, the original tool can continue to live at it's specific URLs and when the new one launches we will have the root URL resolve to immediately display (i.e. redirect) to /introduction. For example:

Old tool:

New tool:

I've removed the draft of launch steps from the body of the ticket, since it seems like we may not go that route. Randi flagged that she or Chris will need to more deeply assess Mikki's notes to finalize the plan. Randi doesn't have capacity for that now, so that might be a good first step for Chris when he's back with us in Sprint 104, to get IA finalized and get this whole thing rolling. cc @FranECross