Deploying a code change to DotCom

Assumptions

In order to deploy a code change to DotCom, an image needs to exist that has the code change. CI builds images that are merged to main and pass all tests.

In extreme circumstances, you can follow the steps here to build an image that bypasses tests.

Manually deploying an image to DotCom

In case an image needs to be deployed faster than the daily release cycle allows, follow these steps:

1. Find the image by either going to the buildkite CI logs on Sourcegraph or searching Dockerhub for the correct tag.

2. The Sourcegraph tag format is [build_number]_[date]_[short git SHA1]

3. Create a branch off the release branch of the DotCom repo

4. Make the relevant image changes in the YAML files

   • Typically, the image will need to be updated in a Deployment or StatefulSet file

5. Create a pull request

6. Request a review from the dev-experience GitHub team (preferable) or another member of the engineering department.

   • Note: 1 approval is required before merging

7. Merge the pull request

8. Once built and deployed verify change was successful

Large releases to DotCom (Rollup releases)

These releases should not be different from our normal release process as long as the below assumptions are true:

• The rollup release does not span a ‘MAJOR’ release (ie v3.32.0 to v3.34.0) would violate our update policy of only upgrading one major release at a time.
• There are not a large (>2) number of migrations between the previous version and the current version of Sourcegraph. This needs to be manually verified by checking the migrations folder of the Sourcegraph repo. The engineer performing the release is responsible for getting the sign-off of the engineers who wrote the migrations.

If the above are true, it is safe to simply update all images to the new release.

Else, releases should be staggered. Either update all images to the next ‘MAJOR’ release or the first release that contains a questionable migration.