Step-by-step guide

Tagging Procedure

  1. On the first day of each sprint, you have to create a git tag for the version of the code that is currently deployed to SIT. This only needs to happen for these repos: 

edsc: https://github.com/nasa/earthdata-search
cmr-graphql: https://github.com/nasa/cmr-graphql
edsc-cmr-preview: https://git.earthdata.nasa.gov/projects/EDSC/repos/edsc-cmr-preview/browse
cmr-ordering: https://git.earthdata.nasa.gov/projects/CMR/repos/cmr-ordering/browse

    git checkout main
    git pull origin main
    git tag -a "v23.4.5-3" -m "Sprint v23.4.5 release"
    git push origin "v23.4.5-3"

After tagging the repo, you need to go to bamboo and update the release version. To set the new version use <PI>.<Sprint>, so in the above example you would set the next version to 23.4.6-0

EDSC: https://ci.earthdata.nasa.gov/deploy/config/configureDeploymentProjectVersioning.action?id=242712580
CMR-GraphQL: https://ci.earthdata.nasa.gov/deploy/config/configureDeploymentProjectVersioning.action?id=287375363
Access (edsc-cmr-preview): https://ci.earthdata.nasa.gov/deploy/config/configureDeploymentProjectVersioning.action?id=374046723
CMR Ordering: https://ci.earthdata.nasa.gov/deploy/config/configureDeploymentProjectVersioning.action?id=406749185


Deployment Procedure

  1. Deployment day is the first Wednesday of each sprint. Deployments are done in bamboo. 
    The process here is to verify that all the tickets include in a release has been verified in the environment before pushing that release to the next environment. 
    SIT -> UAT tickets need to be verified internal. UAT -> PROD tickets need to be verified in UAT, which usually is just a comment on the ticket, not a state change.

    edsc: https://ci.earthdata.nasa.gov/deploy/viewDeploymentProjectEnvironments.action?id=242712580
cmr-graphql: https://ci.earthdata.nasa.gov/deploy/viewDeploymentProjectEnvironments.action?id=287375363
edsc-cmr-preview: https://ci.earthdata.nasa.gov/deploy/viewDeploymentProjectEnvironments.action?id=374046723
cmr-ordering: https://ci.earthdata.nasa.gov/deploy/viewDeploymentProjectEnvironments.action?id=406749185



NPM Repos

  1. Our NPM repos do not have their versions tagged, and they are not deployed on deployment day. 
    Each PR needs to update the version defined in the package.json file (also run `npm install` to update the package-lock.json version). 
    When those PRs are merged, we do an immediate deployment to NPM to publish the new version of the package.
EDSC ECHO Forms 
Repo: https://github.com/nasa/edsc-echoforms
Deployment: https://ci.earthdata.nasa.gov/deploy/viewDeploymentProjectEnvironments.action?id=289767428
EDSC Timeline
Repo: https://github.com/nasa/edsc-timeline
Deployment: https://ci.earthdata.nasa.gov/deploy/viewDeploymentProjectEnvironments.action?id=307003393
EDSC Geo Utils
Repo: https://github.com/nasa/edsc-geo
Deployment: https://ci.earthdata.nasa.gov/deploy/viewDeploymentProjectEnvironments.action?id=398229507
EDSC Smart Handoffs
Repo: https://github.com/nasa/edsc-smart-handoffs
Deployment: https://ci.earthdata.nasa.gov/deploy/viewDeploymentProjectEnvironments.action?id=398229508
EDSC ESLint Config
Repo: https://git.earthdata.nasa.gov/projects/EDSC/repos/edsc-eslint-config/browse
Deployment: https://ci.earthdata.nasa.gov/deploy/viewDeploymentProjectEnvironments.action?id=468647939


Earthdata Download Deployment Procedure

  1. Earthdata Download does deployments differently. Everything is handled in GitHub by GitHub Actions. Each PR needs to update the version defined in the package.json file (also run `npm install` to update the package-lock.json version). After a PR is merged GitHub Actions runs the test suite on the main branch. _After_ those tests are completed you have to create a new tag for the new version.

    git checkout main
    git pull origin main
    git tag -a "v1.4.2" -m "v1.4.2 Release"
    git push origin "v1.4.2"

This new tag will trigger the Build/Release workflow in GitHub Actions, which results in a new 'draft' release to be created. Team members will be able to see this draft release but it is not publicly available yet. The team will use this draft release to perform the ticket verification. _After_ the ticket has been verified with the draft release you can open the draft release and publish the release. This will make the release public and set it to the latest release.