New Component Preparation

When you first become a PO, you will inherit an existing component, but in the future you will likely be part of creating a new component and getting it to production.

Most new components start with 2+ epics in Jira: 1 for the component work and 1 for the initial deployment. The initial deploy epic includes tasks that are required to set up the new component and get it deployed to SQA and production. These are done in coordination with the PM and RM.

New component creation & the initial deploy epic process are great times to shadow other POs or ask for help!

Creating the Repository / Initial Commit

  1. Select which project it should fall under: CKM, VDMS, IUMS, etc.

  2. Click on the + icon and create the repository, set the branch default to main

  3. Create a new repository on your local machine and push the initial commit to Bitbucket

SRVDD / Swagger

The SRVDD and Swagger are the primary tools that external teams use to understand our services. A Software Service Design Document is a technical document that describes how a software product will be built to meet the needs of the client. Both of these are required and should be detailed.

Provide your PM the link to the SRVDD to submit for the VAMFAT review (DHSS). Approvals have to be obtained before you can go to Prod (approved or approved with constraints).

SRVDDs should be kept up to date. Review these at least monthly for all services to make sure they are accurate.

Creating the Sandbox Jenkins Pipeline

When you are ready to get the Jenkins pipeline setup in the sandbox environment, follow these steps:

  1. In Sandbox Jenkins, copy the pipeline from an existing service (I recommend picking a newer service) and renaming it.

  2. Be aware that if the service you cloned exists under a different project (IUMS, VDMS) that you will run into difficulties - if your branches aren’t being populated this is the reason.

POs create the sandbox pipeline first since they can do it themselves. POs work with the RM to submit a ticket for the pipeline to be set up in SQA.

Initial Deployment Epic / Tasks

The initial deployment epic is created for POs by their PM to help track the more administrative tickets. These tasks are required to set up the new component and get it deployed to SQA and production. As the service is getting ready to deploy to SQA, update the tickets and reassign them to the PM / RM:

  • ARB submission and approval (DHSS)

    • VAMFAT reviews are triggered when a service is first being deployed, when a new endpoint is added / changed / deleted and when a new major version is released.

    • Work with your PM to get the VAMFAT submitted early. They’ll need the SRVDD to start this. VAMFAT Reviews take time, a month or more, so POs should get it submitted early before major work is actually being done on the service.

    • When you have a SRVDD ready for review, tag your PM with a link to the SRVDD document in BitBucket. You will need to provide a link at a specific commit, the latest is not acceptable because it may change and all reviewers need access to the same document (example: https://coderepo.mobilehealth.va.gov/projects/CKM/repos/mobile-hrpas-service/browse/docs/SRVDD.md?at=9cccb41e15313b86f807b3d1e40093509201888a)

  • Jenkins Pipeline

    • Fill in the information on the task for the repo link and branches to build (usually Release/* release/*). Also add a short description of what the service is. Then reassign the task to the RM and post in #releases. They’ll post back with the NGD ticket once it’s been submitted and the PO can “watch” it to see when it’s done.

  • Initial deploy: <version> to SQA

    • Once the Jenkins pipeline is set up the service can be deployed to SQA. Update this ticket to include any consul, vault, route or database changes. Reassign the ticket to the RM and post in #releases. They’ll post back with the NGD ticket once it’s been submitted.

    • If the service requires a database you can add it to this ticket or as an additional ticket. You will also include the information here about the type of database, the shell script the DBA executes, and any SQL scripts that need to be executed.

    • If the service requires mobile-oauth-sts registration, you can add it to this ticket or as an additional ticket.

  • Initial deploy: <version> to Prod

    • When you’re ready for the initial release to production, update this ticket with the associated Fix Version. include any consul, vault, route or database changes and update the Artifacts, Deployment conditions and Notes sections. Reassign the ticket to the RM and post in #releases. They’ll post back with the NGD ticket and scheduled release date / time once it’s been submitted and update the upcoming releases list.

    • Note: before the first deployment to production, the vv.yaml should have this for the versions: current: 1.x.x, previous: 0.0.0, type: major

    • If the service requires a database you can add it to this ticket or as an additional ticket. You will also include the information here about the type of database, the shell script the DBA executes, and any SQL scripts that need to be executed.

    • If the service requires mobile-oauth-sts registration, you can add it to this ticket or as an additional ticket.