Skip to content

Releases

Jump to bottom
Rachel Tublitz edited this page Oct 2, 2020 · 16 revisions

Creating Releases

We appoint a release manager from the team, and rotate every month to share the load here (includes devs + em).

On release day, release manager:

  1. Checks for changes to the dependent functional tests that live in the server-syncstorage repo repo. If the tests have changed, we’ll need to create a new server-syncstorage release and manually specify that tag in the jenkins UI in order to trigger manual tests.
  2. Follows these instructions to create a new release as needed: both in the codebase, and as an official GitHub release.

Release Process

For regular releases:

We have an assigned release manager, which will rotate monthly. For regular feature and maintenance work and non critical bug fixes, we follow a predictable 2 week release cycle. This means we have 2 weeks to test new changes against staging before they roll out to production.

  • Releases happen every other Monday.
    • Release calendar is here (internal link).
    • If it’s a holiday/etc we’ll use the release calendar to communicate agreed upon changes accordingly.
  • Staging:
    • If new changes have merged to master since last release, the release manager creates a new release. The release gets automatically deployed to staging.
    • If no new changes have merged to master since last release: no new release is created.
  • Production:
    • If the version in production does not match the version in staging (sometimes it will match if no release was created in the previous cycle), then the release manager files a new deployment request for Ops to manually release to production. This bug is a good example of what should be included in this request - ie, list of changes, required config changes, etc.

Here's an example to illustrate how this process works:

Staging Production
Week 1 v0.0.4 v0.0.3
Week 2 v0.0.4 v0.0.3
Week 3 v0.0.5 v0.0.4

For time sensitive releases:

Most of the time, waiting 4 weeks to roll out a change to production is fine. Sometimes however, we’ll run into something that’s time sensitive and needs to be deployed more quickly. If that’s the case, the release manager can tag a new release at any time, and then follow the steps to request a production or staging deployment.

We’ll track these types of requests [here](Most of the time, waiting 4 weeks to roll out a change to production is fine. Sometimes however, we’ll run into something that’s time sensitive and needs to be deployed more quickly. If that’s the case, the release manager can tag a new release at any time, and then follow the steps to request a production or staging deployment.

We’ll track these types of requests here, in order to understand how often we decide to short circuit the regular release process.

Here’s what happens during the release cycle for these kinds of fixes: ), in order to understand how often we decide to short circuit the regular release process.

Here’s what happens during the release cycle for these kinds of fixes:

Week 1 - staging Week 1 - prod Week 2 - staging Week 2 - prod
Staging fix ("warmfix")
Production fix ("hotfix")
Clone this wiki locally