Release Process
- We have four releases per year, usually at the end of each quarter:
YY.03,YY.06,YY.09,YY.12. - There are two product flavors — Platform and Partner Preview Platform
(PPP). These run as coexisting deployments in separate namespaces. PPP is
usually released one week after Platform. PPP follows the same mechanics in
the
*-pppnamespace with its own images and snapshots.
Useful tools
Overview
A release consist of:
- Ideally a week before release date, start up staging with the new RC images and data snapshots.
- All Teams test staging, apply any fixes that are required there until everything is ready.
- The day before release:
- Build final CH/OS images and tarballs.
- Push release to EBI's FTP.
- Push release to Google Cloud Storage
open-targets-data-releasesbucket. - Push data to BigQuery dev and BigQuery prod.
-
On release day, switch staging and production.
Note
As staging is still up, if anything is wrong the rollback is instantaneous with
helm rollbackor switching back. -
After a couple of days, bring down the old production.
This changes made editing profiles/production-platform.yaml.
And applied with make deploy-chart-prod-platform.
Step-by-step
Tip
Check out the config file for production.
For this example, we assume blue is live and green is idle.
1. Bring up staging
Update deployment config
First, configure the idle colour with the upcoming release image tags and data snapshots.
-
In the
greenblock, set the newwebapp,apiandaiapiimages, theclickhouse/opensearchsnapshots, and thereleasevalue. -
At the start of the file, Set
staging: enabledso the staging deployment is started.
Note
During testing, -rc/-dev image tags and -rcN snapshots are expected here.
Deploy staging
Review the helm diff and confirm. You should see a lot of additions (green lines)
as Helm brings up another whole copy of the infra. Green starts on the staging
node pool (which scales up from 0) and is served at staging.platform.opentargets.org
(plus api. / ai.).
2. Test
First checks you can do:
- Use k9s to check that pods are starting properly. Type
:namespaces, selectproduction-platformand check theproduction-platform-green-*pods by scrolling to them and pressingd. -
Confirm the API reports the expected release and version. For that, go to the Staging API GraphiQL and run the following query:
-
Head into the staging platform and check that things look as they should.
3. Day before release: data publishing
Build images and tarballs
- Once all tests are confirmed to be passing and things look correct, build final versions of the services and generate final snapshots of the data.
- Swap every
-rc/-devimage tag and-rcNsnapshot in thegreenblock to its final value (see Final versions). - Make sure things are still as they should in staging.
[WIP]
Push to EBI's FTP
[WIP]
Push to GCP Bucket
[WIP]
Push to BigQuery
[WIP]
4. Release day: Promote staging to production
- Set
production: green. - Deploy:
make deploy-chart-prod-platform. The prod Services now select green pods. Blue keeps running (now the staging colour) as a rollback. Celebrate the release!
5. Decommission staging
Once the release is confirmed healthy and has been in production for a few days:
- Set
staging: disabled. - Deploy:
make deploy-chart-prod-platform. Blue's workloads and their PVCs are removed and thestagingnode pool scales back to 0.
Rollback
While the old colour is still up (before step 5), rollback is immediate: set
production back to the previous colour and deploy (or helm rollback). To rollback
after having decommisioned the staging env, you must bring the old colour back up
as staging first, then promote it.
Final versions
Staging runs release-candidate artifacts; production must run final ones. As the time to release approaches, appropriate tags should be created for ot-ui-apps, platform-api and ot-ai-api. Same with the ClickHouse and OpenSearch Google Cloud Snapshots.
- Image tags: replace
…-rc.Nwith the final release tag (e.g.26.03.1-rc.4→26.03.1). - Snapshots: replace
platform-2603-ch-rcNwith the finalplatform-2603-ch(same for-os).
Warning
Final versions should be running in staging before release day!
Changing a ClickHouse or OpenSearch snapshot recreates its StatefulSet — the
snapshot name is part of the StatefulSet name — and triggers a full reload
from the new snapshot. It is not an in-place update, so be sure to do this
before the actual release.
Checklists
Pre-release (One week before release)
- ot-ui-apps tag present and has run its CI/CD; image tag exists in Artifact Registry.
- platform-api tag present and has run its CI/CD; image tag exists in Artifact Registry.
- ot-ai-api tag present and has run its CI/CD; image tag exists in Artifact Registry.
- ClickHouse and OpenSearch release snapshots created in
open-targets-eu-dev. - Idle colour configured and
staging: enabled.
Data release (One day before release)
- All
-rc/-devimage tags swapped to final. - All
-rcNsnapshots swapped to final. - Images and tarballs built, present in release bucket.
- Data pushed to EBI FTP.
- Checksums present in the release bucket.
- Push to
open-targets-data-releasesbucket. - Push to BigQuery dev and BigQuery prod.
Release day
-
productionflipped to the new colour.
Post-release
- Create the release branch/tag in
ot-snapshot, pinning the final component versions. - Staging decommissioned (
staging: disabled) after the grace period. - Production re-verified after teardown of staging.
Troubleshooting
Tip
We should write down usual problems and the solution here.