Deploying a code change to Sourcegraph Cloud

Assumptions

In order to deploy a code change to cloud, 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.

Deploying the image to Cloud

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. Make the relevant image changes to the YAML files in the cloud repo

   • Typically, the image will need to be updated in an deployment or statefulset file

4. Create a pull request against the release branch of the cloud repo.

5. Request a review from the cloud-devops github team (preferable) or

   • another member of the Cloud organization.
   • In the future, 1 approval may be required before merging

6. Merge the pull request

7. (Optional) View the CI run on the branch to ensure CI successfully rolls out the change.

Large releases to Cloud (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.