Skip to content

Development environments

Jump to bottom
Derek Fitchett edited this page Oct 16, 2024 · 43 revisions

For more detailed description of the LHDI environments available to VRO, skip down to the VRO Environments section.

Environments

Environment Claims API (Env) / URL CorpDB BGS (external/internal) VBMS vets-api
dev (Test) https://claims-test.dev.bip.va.gov/api/v1 DEVL http://bepdev.vba.va.gov DEV N/A
qa (Integration) https://claims-int.dev.bip.va.gov/api/v1 WEBTEST http://bepwebtest.vba.va.gov TEST N/A
sandbox (UAT) https://claims-uat.stage.bip.va.gov/api/v1 LINKTEST http://beplinktest.vba.va.gov UAT Staging
prod-test (PreProduction) https://claims-preprod.preprod.bip.va.gov/api/v1 PPRD3 https://bepprep.vba.va.gov PREPROD N/A
prod (Production) https://claims-prod.prod.bip.va.gov/api/v1 VBA1 https://vbmsprod.vba.va.gov PROD Production

Current Environments in use by downstream BIP Claims API.

TLDR 2024

LHDI 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 for both Core and Partner team deployments, meaning that a release tag has been placed and the versioned build artifacts are deployed. In this sense, Sandbox would be our most stable test environment and a last stop before prod and prod-test. Since we would have already created a release branch, it is safe to say that both Core and Partner team images have been tested and validated by this point.
prod-test VRO Core and Partner Teams Prod-test includes all the same requirements as sandbox, with the primary difference being that prod-test lives the prod cluster of LHDI. This means that images that have been deployed to prod test are both a release branch and SecRel signed.

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. Note that for partner teams you should replace abd-vro in the following URLs with your team-specific name.

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.lighthouse.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