DUW: Launch plan

[jilladams]

Status

[2024-12-13] [Fran] Ready to release on Monday, Dec 16!

Pre-launch

• All content and logic changes have been implemented
• Collab ticket for Staging review has been submitted
  • Privacy, Security, and Readiness Review ticket submitted
    • Privacy, Security, and Readiness Review passed
  • Product Guide submitted to Contact Center Team
    • Product Guide passed/accepted
  • Accessibility Artifact ticket created
    • Accessibility ticket has been completed
  • QA Standards have been met according to this ticket
    • QA Artifact created; link added to collab cycle ticket.
    • Note that the lack of a Traceability Matrix is not launch blocking; Fran has one started, but it's very convoluted and will be a work in progress.
  • Staging Review has occurred and feedback received
    • CAIA Staging review launch blocking feedback (if any) is implemented
  • Collab cycle ticket (s) have been addressed/closed
• Greenlight from CAIA that all updated text has been provided and implemented
  • CAIA has successfully QA'd and Passed all content on Staging (Intake review ticket)
  • PW team members tagged for QA have successfully tested and Passed all logic flows according to this [Mural or Test plan?]
• Analytics ticket has been submitted

Go / No Go

• Greenlight from Michelle Middaugh for launch
• Greenlight from Danielle Thierry for launch

Launch

• Content-build PR [PR #] must be merged after 10am ET but before COB the day before launch in order to actually deploy the DUW app to prod ticket.
• Redirect must be merged to send folks to the new wizard
• Content-build deploys successfully, including our commit (Deploy job; (Deployment schedules on VA Platform).
• App is live at https://www.va.gov/discharge-upgrade-instructions/introduction
• Any socialization/announcements needed have been sent
• Ensure all associated (completed) collab cycle and epic tickets are closed

Day After Launch Day

• 508 Audit Request has been filed
• Add info to ToT PW slide for socialization - remember Party Cone!
• Communication to:
  • Digital Modernization Council: Danielle and Michelle to include an update on this in their next readout to the digital modernization council
  • Joshua Gibbs & (Danielle T will provide other folks to send to)
  • Danielle Thierry
  • PW Team
  • ToT slides (party cone!)

Post Launch

• Remove old DUW code after we ensure the new wizard is functioning correctly.

[FranECross]

@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]

@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]

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

[jilladams]

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:

• va.gov/upgrade-discharge-instructions
• va.gov/upgrade-discharge-instructions/questions
• va.gov/upgrade-discharge-instructions/guidance

New tool:

• va.gov/upgrade-discharge-instructions/introduction
• va.gov/upgrade-discharge-instructions/[question-1-slug]
• va.gov/upgrade-discharge-instructions/[question-2-slug]
• va.gov/upgrade-discharge-instructions/review
• va.gov/upgrade-discharge-instructions/results
• After launch we redirect or add code to the old page to render the new /introduction page. This is how many of the forms on VA.gov work in regards to having a canonical URL that then resolves to the appropriate first page of the form flow.

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

[jilladams]

@FranECross Updated this with everything I know we have done so far. Not sure about the comms pieces -- I think you can feel free to close this whenever it feels done enough from your perspective.

[FranECross]

We have plans to communicate with a few other folks, and also a ticket to remove code, but that won't be worked on until early 2025. Closing ticket.