search

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
97 stars 69 forks source link

SPIKE: Support UAT / launch of 1095-B #10327

Closed jilladams closed 2 years ago

jilladams commented 2 years ago

Description

1095-B Preview page: http://preview-prod.vfs.va.gov/preview?nodeId=44346 Node: https://prod.cms.va.gov/download-your-irs-1095-b-tax-form

It's a CMS page with a React widget

Stakeholders: @Tamera Ann Corson, Shashank @Khandelwal (technical contrib)

Customer wants:

Desired Launch timeline:

Tasks / plan / options

In order to manage visibility of this page/ contents:

Prerequisites

  1. Page created in production CMS as Draft
  2. Entity (node) ID of the page in Drupal shared with PW
  3. Contributing team: Push the code for their react widget to main

Option 1: If page can be accessible on prod only if user has the URL

  1. We need to prevent the page appearing in sitemap.xml -- (CMS codebase? TODO research)
  2. Add noindex to it (addNoIndexMetaTag) to block the pages in robots.txt -- content-build
  3. Using flipper: We can set up a flipper that will control how many users can see the widget on your page, but cannot control visibility of the entire page itself. Meaning: any user with the link could visit and see the page without displaying the React widget. May not be useful in this context -- check with customer.
    • If flipper for widget only: relatively small lift. (New flipper)

Option 2: Publish the page to Staging, not Production, for user testing We can write content-build custom code to conditionally not build this node in production build (e.g. homepage-test). - lift = content-build is difficult to debug, 2 days no distractions, 1 week with regular load

Option 3: Tugboat Team just needs CMS content + React widget available somewhere to demo to a Veteran for confirmation that it works. This could happen in Tugboat, we think. Need to provide steps / guidance for the how.

Additional details

Acceptance Criteria

CMS Team

Please check the team(s) that will do this work.

jilladams commented 2 years ago

Team to leave Flipper in place, no slow rollout, will go straight to 100%. However: currently cannot test However: do need to do UAT with the built page + React widget. Requires publishing the CMS page somewhere (Tugboat, Staging?), with React widget available.

If we offer Tugboat, need to offer documentation -- 1095b team isn't familiar.

jilladams commented 2 years ago

Tugboat for devs: https://github.com/department-of-veterans-affairs/va.gov-cms/blob/main/READMES/tugboat.md Tugboat for non devs: https://prod.cms.va.gov/help/how-to-release-content-in-the-demo-environment

jilladams commented 2 years ago

@davidconlon (cc @ryguyk @swirtSJW @wesrowe) Decision point: we cannot support the ask for making 1095B CMS + React widget (vets-website code) available off VA network for UAT, without exposing the page to prod, with the current available tech. We'll need to do custom work to support the ask. Summary of options is followed by a round up of what's available today and how it all works, for the history books / future reference.

Options to support 1095B user testing

Option 1: Install Node Queue module - PREFERRED -- 5-8 points

Node Queue allows you to create lists of specific nodes by ID, and the list information can be harnessed in build steps. In this case, we can create a "Publish to Staging, not to Prod" Node Queue, and update content-build to respect it. That would allow this team to view their content in Staging for UAT. Nodes in this state (draft in Prod, exposed in Staging) will still count against node count for Build purposes. For now, could be configured so only Drupal Admins can add Nodes to Queues; could potentially extend to Content Admins / others later.

Option 2: Write custom code to exclude this page from robots.txt / sitemap

Right now, both robots.txt & sitemap operate at a template level. We don't currently have a working example of excluding a single node from either one. The effort here is not known, and this is not the preferred option because it creates tech debt with custom code, and sets up a pattern for experimentation in production, which is not ideal.) If we do lean to this route:

Shadow launch / dark launch

Meanwhile, we learned a lot for the sake of this ticket. Documenting here for the histories:

It is not currently possible to

It IS currently possible to

1. Use vets-api “Flipper” feature toggles to show / hide page sections or react widgets (vets-website changes)

Flippers cannot control visibility of an entire page to unauthenticated users or prevent it from being accessed. Once a page exists in production, Flipper can control visibility of the element it's wrapped around. Flipper controls can show/hide:

A good summary of how to flipper: https://github.com/department-of-veterans-affairs/va.gov-team/issues/8853#issuecomment-625426153

Flippers are typically using javascript, and do not require a code deploy to enable / change settings.

2. Write custom vets-website code to control traffic to unauthenticated element / widget

With the release of chatbot, custom code was written to allow % traffic gating for unauthenticated visitors to the chatbot React widget.

3. Use CMS feature flags to show / hide fields or portions of templates in content-build

CMS Feature flags can control visibility from the template layer, but cannot control query content / behavior. CMS feature toggles take effect at the content-build level, and are not dynamically controlled with javascript, so do require a content release to take effect in prod.

For example, if a new feature is launching, that calls new fields / exposes new layout of a template, we may use CMS feature flags to wrap the new markup in order to show / hide the changes for testing or to simplify rollback.

We try to avoid page-specific templates, so for example, we would not advocate controlling launch of content for a single page using this method. This is more a content type level option.

4. Use content-build environment checks to publish a static page only to staging

This only applies to static pages, not CMS content. In content-build, we can exclude a static page from production builds.

PW team has done this twice:

  1. Published a static page for Harassment Reporting Tool, #35161 [FE] Build static landing page in Staging environment
  2. Published a homepage prototype for UA testing, /homepage-test: #8340 Iterate VA.gov homepage changes for demo/testing in publicly accessible environment; PR

Gotcha: this method creates tech debt, and can cause unexpected behavior in future, when we test in Staging and end up with different behavior in Production. E.g. Feature A tests well in staging, but when we reach Prod, behavior is different due to a forgotten environment check in old / untouched code.

Some nuances: https://dsva.slack.com/archives/CT4GZBM8F/p1660937436605269 If I misstated anything here, please edit the comment directly to correct it. (Ryan, I talked with Steve more today after our convo yesterday, hence the changes to our stance on robots/sitemap possibilities.)

jilladams commented 2 years ago

CMS - ~1 day

FE - 3-4 days

Only outstanding question is priority vs. homepage items.

jilladams commented 2 years ago

10374 tracking Drupal

10375 tracking Front-end

jilladams commented 2 years ago

Per Daniel, the NodeQueue module is only for D7. For D8+, entityqueue is the module we need.