Production Deployment

Validating the Development Branch

Note: If you're pushing changes to multiple services (eg Server and Worker), validate them one after the other. If you validate both at the same time, they will conflict with each other.

1. Verify that the latest change in the develop branch successfully built in Travis. If not, wait for the build to complete. This may take up to 12 minutes.
2. Open up your AWS console and navigate to the Elastic Beanstalk environment bridgeserver2-develop. Verify that the deployment has finished. If not, wait for the deployment to finish. This may take a couple minutes after the Travis build completes.
3. Navigate to Jenkins. (Note: You will need to use the VPN.) Log in and click Build Now. This will begin integration tests, which takes about 20 minutes.
4. If the integration tests succeed, the development branch has been validated.

Creating a Release

1. Use the code name generator to generate a code name for the release.

2. In GitHub, browse to Releases (on the right nav bar of the GitHub project).

3. Click "Draft a New Release". The tag should be in the form "release-yyyymmdd". The release title is the code name you generated. Fill in the description with the following template:

   (Name generated from https://thestoryshack.com/tools/code-name-generator/)

   • BRIDGE-nnnn - Jira title here, explanatory notes recommended
   • BRIDGE-nnnn

4. Publish the release.

5. Do the same for Integration Tests, if any changes exist. The description can just say "See BridgeServer2's [release name] release notes." (You don't need to create releases for JavaSDK or any other dependent packages.)

6. Your release is now ready for review!

Push to Staging

Note: You should only push changes after they have been approved in the release meeting.

Note: If Infra changes are needed, you should push out the Infra changes before their corresponding code changes (ie Server-Infra before Server, Worker-Infra before Worker, Exporter-Infra before Exporter). Pushing them out at the same time will cause conflicts in Elastic Beanstalk. You can follow the same steps in this wiki.

1. Go to a local repository dedicated to releases. This repository should be a separate repository locally that does not have ongoing work. As the release process does not need the developer fork, the local repository can be cloned directly from the Sage-Bionetworks remote repository git clone https://github.com/Sage-Bionetworks/BridgePF.git [optional directory name].
2. git fetch origin tag release-20210818 - This fetches the specified tag from GitHub. (Replace release-20210818 with your release tag.)
3. git checkout uat - This switches the branch to the staging (uat) branch.
4. git merge --ff-only release-20210818 - This merges your release to staging. The --ff-only ensures there are no unexpected changes in your staging branch.
5. git log - Shows the state of your local repository. Briefly verify that the top (latest) change matches with the latest change in your release.
6. git push - Pushes the merged changes back to GitHub.
7. If you have changes to the Integration tests, you should also merge those changes to Staging following the same steps as above.
8. Validate staging using similar steps as described in Validating the Development Branch. (If you need to make Infra changes, you can push out both Infra and Server and then run the validation steps once.)

Once staging is validated, you can push to Production following similar steps.