Platform Console - Console Services: Promote Vets-API with EKS to Staging

[npeterson54]

Problem Statement

In order to get Vets API into a state where it can be broken down into micro services, we first want to move into EKS in staging, then into production. This will ease the transition into a micro services architecture. We might solve this by staging a phased rollout into staging that we can rollback as necessary or possibly discover other testing solutions to ensure parity between the two deployment methods

Hypothesis or Bet

This will be a big step in getting Vets API into production with EKS and ultimately make it easier to break down the Vets API monolith into micro services. This will also be a big step in being able to employ continuous delivery.

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

• We have parity between the BRD architecture and the new Kubernetes architecture .
• We employ a rollout strategy that starts with a small percentage of endpoints going live, and eventually reach 100%, with each endpoint working as intended.
• Dead endpoint are identified and a solution to resolve/remove it is given.

Known Blockers/Dependencies

• We do have a dependency on the Infrastructure team, they are aware of it and are planning to help where needed.
  • They may need to help standing up a testing instance or
  • Possible load balancing solution for the phased rollout to staging
• We may have a dependency on the Testing Tools team, but that is still unclear

Projected Launch Date

• Q3 2022

  Launch Checklist

Guidance (delete before posting)

This checklist is intended to be used to help answer, "is my Platform initiative ready for launch?". All of the items in this checklist should be completed, with artifacts linked---or have a brief explanation of why they've been skipped---before launching a given Platforminitiative. All links or explanations can be provided in Required Artifacts sections. The items that can be skipped are marked as such.

Keep in mind the distinction between Product and Initiative --- each Product needs specific supporting documentation, but Initiatives to improve existing Products should reuse existing documentation for that Product. VSP Product Terminology for details.

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
• [ ] External-facing: a User Guide on Platform Website exists for this product/feature tool
• [ ] (if applicable) Post to #vsp-service-design for external communication about this change (e.g. 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.

When you're ready to launch...

• [ ] Conduct a [go/no-go] (https://vfs.atlassian.net/wiki/spaces/AP/pages/1670938648/Platform+Crew+Office+Hours#Go%2FNo-Go) when you're almost ready to launch.

Required Artifacts

Documentation

• PRODUCT_NAME: directory name used for your product documentation
• Product Outline: link to Product Outline
• 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: link to where success metrics are measured, or where they're defined (Product Outline is OK), or provide reason for skipping
• Release plan: link to Release Plan ticket

TODOs

• [x] Convert this issue to an epic
• [x] Add your team's label to this epic
• [ ] Add this initiative to the Digital Experience Product Board using these instructions

[npeterson54]

This is in the correct swimlane

[td-usds]

This has been supplanted by #46779