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.

Manually deploying an image to Cloud

All changes deployed to Cloud should be staged and tested in preprod first before releasing to production.

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 preprod branch of the cloud repo

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

   • another member of the Cloud organization.
   • Note: 1 approval is 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.

8. Once deployed, verify change is live and successful in preprod

Changes deployed to preprod will be automatically released to production on a fixed schedule. If a change is urgent and needs to be deployed to production quickly:

1. Create a branch off the release branch of the cloud repo

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

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

   • another member of the Cloud organization.
   • Note: 1 approval is required before merging

4. Merge the pull request

5. Once built and deployed verify change was successful

6. Then create a branch off preprod

7. Cherry-pick your changes onto this branch

8. Submit a PR to merge those changes to preprod. Note in the PR that the changes are already live on Cloud.

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.