Description
Status
Update each week until completed
| Date | Status | Launch Date | Notes |
|---|---|---|---|
| 2/28/25 | In-progress | TBD | Sprint 22: Reviewing Lighthouse API documentation to determine if adjustments are needed for AuthHeader classes with the new Lighthouse integration. The current implementation was configured specifically for EVSS, and we should verify whether the API calls, headers, and other parameters will differ significantly with the new integration. Specifically, 5 EVSS services will be investigated. No challenges or blockers at this time. |
| 2/21/25 | In-progress | TBD | Sprint 21: Migration of a few of the shared service abstractions continued. Next sprint, a developer will review the Lighthouse API documentation to determine if adjustments are needed for AuthHeader classes with the new Lighthouse integration. The current implementation was configured specifically for EVSS, and we should verify whether the API calls, headers, and other parameters will differ significantly with the new integration. The PM, TL, and key developers are attending a bi-weekly EVSS meeting hosted by the Lighthouse Team to learn more about the in-progress work for specific services, connect with points of contact, share additional information from the knowledge the team has discovered to fill in gaps, and to provide updates on the work the SRE Team is doing. |
| 2/7/25 | In-progress | TBD | Sprint 20: We achieved alignment with stakeholders and leadership on the scope for the Platform-owned components, and the role that the SRE Team will first take on to provide the most effective support for the migration. In the upcoming sprint, the SRE Team will begin migrating a few of the Shared Service Abstractions that currently lack clear ownership or have multiple owners, ensuring a more cohesive and maintainable approach. Also, because the VFS Benefits & Disability teams predominantly own the EVSS services, the SRE Team will provide guidance on the key aspects that need to be addressed in the migrations, ensuring consistency and helping to shape the most standardized solution possible. The current challenge is sorting through the immense number of elements that factor into this migration to gain a deeper understanding of the complex dependencies - and where SRE Team assistance can be most effective. |
| 1/31/25 | Discovery | TBD | Sprint 20: Discovery continues with investigation of the deprecation path for 2 Platform-owned services to determine which would be the best candidate to migrate first. Also, to evaluate the risks and benefits of using Lighthouse endpoints versus VA Profile replacements for EVSS. Also, the Product Outline documentation is being drafted. There is a sync with the TL and developers scheduled on Monday to align with all of the information that has been gathered so far and decide on a technical approach, and after that tickets will start to be written up for a sub-epic. The current challenge is sifting through the EVSS Transition Meeting spreadsheet which outlines the 3 phases the VFS Teams have planned for this migration. I'm comparing the services they have identified to the services the Platform Team has identified to determine what services have already been migrated, what services are already owned by a VFS Team, and confirm the Platform-owned services. |
| 1/24/25 | Discovery | TBD | Sprint 19: Discovery on migration approaches for which endpoints to use (for a service that is a lower lift) is in progress. As the approach becomes more clear, there will be discussions with Platform Leadership and OCTO Stakeholders for feedback and to get alignment. The epic and sub-epics will be built out as more information as more information is available. |
| 1/17/25 | Discovery | TBD | The initial discovery is complete and findings are documented in the EVSS Services & Associated Teams spreadsheet. This spreadsheet lists each service (main and sub-service) within EVSS and the owning team(s). Also, a design document has been created and is being refined. As discussed with the stakeholders and leadership on 1/16, I will continue to build out the sub-epics in this epic that represent the 12 EVSS services. Starting with the "low hanging fruit" of a service that is potentially a lower lift that can be worked on fully by the Product Team/new SRE Team. The current challenges are figuring out an approach to coordinate with the VFS teams that own each service and to ensure the team that established the target deprecation date of late March is aware that target is highly improbable. |
| 1/10/25 | Discovery | TBD | The initial discovery is wrapping up and the findings are documented in the EVSS Services & Associated Teams spreadsheet. This spreadsheet lists each service (main and sub-service) within EVSS and the owning team(s). Also, a design document is being created. |
Problem Statement
To facilitate the transition from the soon-to-be-retired Enterprise Veterans Self Service Portal Platform (EVSS), firstly the new endpoints need to be made available for consumers in the Lighthouse API. Subsequently, all services need to be migrated to the Lighthouse API, and all EVSS references should be removed from every repository.
The initiative is largely owned by the Veteran Facing Services (VFS) Teams, however, as the SRE Team on the VA.gov Platform, we play a critical role in maintaining the health, uptime, reliability, and stability of the monolithic Rails (Vets API) application that powers the Platform. Additionally, some components have widely shared ownership and usage, and the SRE Team may need to assist or take on a specific role in migrating core abstractions and classes to ensure a smooth transition.
It is worth nothing that EVSS is the largest direct integration with an external service that exists in vets-api (with the exception of any services that are sign-in related). Given the complexity and interconnected nature of the codebase and external service integrations, the Platform must ensure the overall health - including compliance with ATO requirements.
The main challenges in the deprecation effort arise from the following:
- Subdividing the EVSS epic effort into task-oriented tickets (by directory/component/service).
- Identifying the primary team associated with each component/service (Platform vs VFS).
- Determining the lift effort associated with removing each aspect of EVSS, along with associated specs.
- Utilizing traffic from logs to make assumptions on which services are most/least/no longer used.
High Level User Story
As a Platform SRE team engineer,
I want to assess and define the necessary base class configurations for migrating EVSS Service Integrations to Lighthouse, so that the transition is seamless, aligns with Lighthouse requirements, and provides a standardized foundation for VFS teams.
Hypothesis or Bet
If the SRE Team acts as a steward for the EVSS migration and provides guidance on key aspects then there will be increased standardization in the codebase which will result in performant and maintainable Veteran-centered applications.
OKR
2025 OKRs
O2: OCTO’s platforms are the fastest, most efficient, and most secure way to deliver products at VA.
Definition of Done
What must be true in order for you to consider this epic complete?
TBD
High Level Tasks
- Initial discovery
- Design documentation
- Consistent coordination and syncs with the Lighthouse Team & key VFS Teams.
- Audit the base classes for 10 EVSS services to evaluate if all components have been migrated and advise on opportunities for code cleanup.
- Provide guidance to the VFS Teams on the key aspects that need to be addressed in the migrations, ensuring consistency and helping to shape the most standardized solution possible.
Related Docs
- Lighthouse APIs
- EVSS Lighthouse Transition Details and Roadmap Spreadsheet (login with CAG to access)
- EVSS Migration Playbook - Lighthouse.
- Artifact: EVSS Deprecation and Migration Discovery
- Artifact: EVSS: Migration Base Class Discovery.
- Artifact: ALL endpoints still currently utilizing EVSS
Activity