Skip to content

Development environments

Jump to bottom
Erik Nelsestuen edited this page Feb 7, 2024 · 43 revisions

TLDR 2024

| ENV | Primary Use Case | Description | | dev | VRO Core Team | Not recommended for partner team use - Since this environment almost always contains VRO Core feature branch deployments, it is not a good environment for partner team use. VRO Engineers will use slack to sync up on what feature branch is deployed and should include an estimated time period of use. Feature branch coordination may warrant a slack canvas if needed, especially if there ends up being a queue of deployments waiting for dev environment availability.| |qa|VRO Partner Teams| Recommended for partner team use - The QA environment will typically contain the active release branch, which is either going to be the same as the present production deployment or may also contain the active release tag. This could be the develop branch if there is a desire to test a stable develop branch prior to cutting a release tag. | | sandbox | VRO Core and Partner Teams | Sandbox would always contain a release branch, meaning VRO release tagged builds. Sandbox would be our last stop before prod and prod-test, so we should have already created a release branch by this point.|

VRO Environments

Development (non-prod) and prod environments for the various systems, APIs, and data sources with which VRO interacts.

Following Environments are Available for VRO

DEV

  • The purpose of the development environment is to provide a controlled space for software developers to create, modify, and test new features, enhancements, or bug fixes. Developers have the freedom to experiment without affecting the stability of the production system. Developers use the DEV environment to write and test code, integrate new features, and collaborate on software development tasks.
  • Runs mainly on Develop Branch and is frequently Updated.
  • https://dev-api.va.gov/services/abd-vro/

QA

  • The QA environment is dedicated to testing and quality assurance activities.Teams use this environment to perform various types of testing, including functional testing, regression testing, performance testing, security testing, and user acceptance testing.More stable then DEV environment and is manually updated.
  • Can be used by team for manual testing
  • Internal:
  • External:

Sandbox

Prod-test

Prod

See Also:

Prior RRD Testing

Testing the RRD prototype involved these environments:

  • va.gov staging user
  • Lighthouse sandbox
  • VBMS uat
  • EVSS pint and VBMS uat interact with the linktest (fake) data.

We'll likely do something similar for testing VRO.

  • EVSS preprod corresponds with VBMS prodtest

VRO v1 Testing

  • va.gov staging
  • Lighthouse sandbox
  • VRO sandbox (sandbox.lighthouse.va.gov/abd-vro)
    • VRO v1 connects to only Lighthouse (not VBMS or EVSS)
  • VBMS uat
  • EVSS pint and VBMS uat interact with the linktest (fake) data.

VRO v2 Testing

  • va.gov none - no prod-test env exists
  • MAS prodtest
  • Lighthouse prod
  • VRO prodtest
  • VBMS prodtest

LHDI

On the nonprod cluster:

On the prod cluster:

See Kubernetes clusters for details

va.gov

va.gov (a.k.a. vets-api)

From VA Platform doc and devops repo

Lighthouse API

From Lighthouse doc

Lighthouse Sandbox Test Patient Data Management

  • There's 2 ways to submit requests to the Health API team:
  • A few reminders:
    • It's okay to send one email that includes the creation of 3 health test patients, for example, but if subsequent changes are needed to the health data for those 3 test patients, a new email should be sent
    • Keep [email protected] in the cc line of the email when responding to requests and questions
    • Specify that the request is for health test patients
    • Indicate which team the request is coming from
    • Request does not need to be in a specific format, but be as specific as possible
  • Estimated turn around time: ~1 week, depending on the intricacies of the change

VBMS

VBMS Overview

Logins

In order to login you need:

  • Station IDs: the 3-digit number that corresponds to your Regional Office. We usually use 283 for Developers. ARC is 397, and Florida is 317.
  • User ID: is the Active Directory account name under which you will authorize access.
  • PIV card

For VBMS Prod access

For VBMS ProdTest access

  • you must have access to VBMS Prod
  • email [email protected] to be added to the ProdTest URL mailing list, which changes daily.

Local Testing of VBMS and BGS

EVSS

  • INT
  • PINT (aka SQA or staging)
  • PreProd
  • Prod

CMP/MAS

CMP (a.k.a. MAS - Mail Automation Systems)

MAS tests its OCR function in VBMS prodtest

Old related ticket

MPI

MPI (Master Person Index, a component of Master Veteran Index (MVI) or formerly known as MVI or Master Patient Index)

MPI can be used to get the Integration Control Number (ICN) for a given veteran.

  • Lighthouse Veteran Verification API v2 could provide this lookup capability. API-17363 will look into the feasibility of this (Slack).

Resources

Clone this wiki locally