Frontend App Architecture — Discovery: Frontend solution that will enable autonomous VFS deploys

[meganhkelley]

Problem Statement

VFS teams all use the same repository for the FE apps vets-website, which means that there are a significant number of interdependencies between more than a dozen teams working in the same repo. For example, when one team's unit test fails, the entire website deploy is blocked.

How might we (determine an approach that will) reduce interdependencies between VFS teams and enable them to work more autonomously?

Hypothesis or Bet

• If we reduce interdependencies between VFS teams, then the Platform will be more scalable.
• If we reduce interdependencies between VFS teams, then VFS teams will be able to work more iteratively.

We will know we're done when... ("Definition of Done")

• [x] Research with VFS teams is complete and synthesis has been presented
• [ ] Technical solution approach has been proposed (design doc)
  • [ ] Proposal includes proof of concept to validate the approach
  • [ ] Proposal includes assessment of alternative approaches
• [ ] Solution approach approved by Platform leadership

Known Blockers/Dependencies

• May need support from Service Design and/or Naomi to conduct VFS team research
• Numerous Platform teams will need to give feedback on and sign off on technical approach — heavy coordination involved
• Overall approach and strategy should be aligned across multiple Platform teams

Projected Launch Date

• Q3 2021 (solution finalized only, to be implemented beginning in late Q3/Q4)

Launch Checklist

Guidance (delete before posting)

Is this service / tool / feature...

... tested?

• [ ] Usability test (TODO: link) has been performed, to validate that new changes enable users to do what was intended and that these changes don't worsen quality elsewhere. If usability test isn't relevant for this change, document the reason for skipping it.
  • [ ] ... and issues discovered in usability testing have been addressed.
  • Note on skipping: metrics that show the impact of before/after can be a substitute for usability testing.
• [ ] End-to-end manual QA or UAT is complete, to validate there are no high-severity issues before launching
• [ ] (if applicable) New functionality has thorough, automated tests running in CI/CD

... documented?

• [ ] New documentation is written pursuant to our documentation style guide
• [ ] Product is included in the List of VSP Products
  • List the existing product that this initiative fits within, or add a new product to this list.
• [ ] Internal-facing: there's a Product Outline checked into products/platform/PRODUCT_NAME/
  • Note: the Product Directory Name should match 1:1 with the List of VSP Products
• [ ] External-facing: a VFS-facing README exists for this product/feature tool
  • [ ] ... and should be located at platform/PRODUCT_NAME/README.md
• [ ] External-facing: a User Guide exists for this product/feature/tool, and is updated for changes from this initiative
  • [ ] ... and should be linked from the VFS-facing README for your product
  • [ ] ... and should be located within platform/PRODUCT_NAME/, unless you already have another location for it
  • [ ] (if applicable)... and post to #vsp-content-ia about whether this should be added to the Documentation homepage
• [ ] (if applicable) Post to #vsp-service-design for external communication about this change (e.g. VSP Newsletter, customer-facing meetings)

... measurable

• [ ] (if applicable) This change has clearly-defined success metrics, with instrumentation of those analytics where possible, or a reason documented for skipping it.
  • For help, see: Analytics team
• [ ] This change has an accompanying VSP Initiative Release Plan.

Required Artifacts

Documentation

• PRODUCT_NAME: directory name used for your product documentation
• Product Outline: App deployment platform product outline
• README: link to VFS-facing README for your product
• User Guide: link to User Guide

Testing

• Usability test: link to GitHub issue, or provide reason for skipping
• Manual QA: link to GitHub issue or documented results
• Automated tests: link to tests, or "N/A"

Measurement

• Success metrics:
  • Success metrics for implementation of autonomous deploys are TBD
  • Because this initiative is for discovery and solution approach proposal, success = completion of the initiative, as described in definition of done above
• Release plan: link to Release Plan ticket

TODOs

• [x] Convert this issue to an epic
• [x] Add your team's label to this epic

[meganhkelley]

Initial ticket for micro-frontends (closed to reduce noise for people who have left the Platform): https://github.com/department-of-veterans-affairs/va.gov-team/issues/1099

[mpelzsherman]

Here's a Google Doc with some background info and a high-level proposal.

[meganhkelley]

@mpelzsherman Hey Michael, I do not have access to that doc

[mpelzsherman]

@mpelzsherman Hey Michael, I do not have access to that doc

Sorry @meganhkelley. I've updated sharing on the link and you should have access now.

[mpelzsherman]

The biggest pain point this would solve is reducing build times for VSA pull requests. Currently, all PR's build all of the applications, even though VSA developers work on only one app at a time. A flaky test in another app can cause a PR build to fail, requiring a re-build. Separating the apps would make our PR builds much faster, resulting in a huge gain in efficiency.

Note: our review environments do not need to be fully-functional copies of all of VA.gov. They only need to support the app under development.

[meganhkelley]

Update:

• Research with VFS teams has been completed and synthesis presented
• High level proposal being drafted by FE Tools team, which will be shared by end of month