Project

General

Profile

Actions
History

Wiki »

Release Checklist

Pre-process:

  1. Create an issue for the release.
  2. Add each of the following steps (starting at step 1) as tasks with the step number in the subject
  3. Assign each task
  4. The current task goes into the "In Progress" column
  5. When the current task is finished, move it to resolved, and move the next task into "In Progress"
  6. Notify the assignee of the next task that it is ready to begin

Meta-process:

  1. Periodically review this documented process reflects our actual process & update it
  2. When steps are added/changed/rearranged/removed, be sure to update cmd/art/TASKS in the arvados-dev repository.
Step Who What
0 engineering Build new features, refine good code into great code
1 ops Build a new tordo compute image against the latest development packages.
Test it with a couple representative workflows (at least one bioinformatics workflow and one S3 download workflow).
If everything works well, update version pins based on the versions installed in the new image. Update:
* source:tools/ansible/roles/arvados_apt/defaults/main.yml (update arvados_pin_version)
* source:tools/ansible/roles/arvados_docker/files/arvados-docker.pref
* source:tools/ansible/roles/compute_amd_rocm/defaults/main.yml (update arvados_compute_amd_rocm_version)
* source:tools/ansible/roles/compute_nvidia/files/arvados-nvidia.pref
2 engineering Prepare release branch on the arvados and arvados-formula repositories. For major releases, this means branching a new X.Y-staging from main. For minor releases, this means cherry-picking features onto the existing X.Y-staging branch. Ensure that Redmine issues for features or bugfixes that are appearing for the first time in this version are associated with the correct release (for major releases, use art redmine issues find-and-associate).
3 engineering Ensure that the release staging branch passes automated tests on Jenkins.
For major releases, this means:
* developer-run-tests
* developer-run-tests-doc-sdk-java-R
For minor releases, this means:
* X.Y-developer-run-tests
* X.Y-developer-run-tests-doc-sdk-java-R
4 engineering Review release branch to make sure all commits that need to be in the release are in the release. If new commits are added, resume checklist from step 3.
5 product mgr Write release notes and publish them to www-dev site: https://www-dev.arvados.org/releases/
6 everyone Review release notes
7 product mgr Create a Redmine release for the next patch release after the current one.
8 release eng Build release candidate packages with version "X.Y.Z~rcN-1" using the Jenkins job build-and-publish-rc-packages. Add a comment on the release ticket identifying the Git commit hash used for the build, and link to your Jenkins run.
9 release eng Publish release candidate arvados/jobs Docker image using docker-jobs-image-release
10 ops Test installer formula / provision scripts with RC packages - Installer development process
11 ops Build a new compute image and update Playground using the new RC packages and compute node image
12 bfx Run CWL conformance tests on jenkins and bam-to-vcf pipeline on Playground
13 engineering Perform final manual testing based on risk assessment, the release notes and manual testing plan.
14 product mgr Approve RC for release
15 release eng Publish Ruby gems using build-publish-packages-python-ruby
16 release eng On the X.Y-staging branch, update these files to refer to the release version:
* doc/admin/upgrading.html.textile.liquid the "Upgrading Arvados and Release notes" doc page with the version and date of the release.
* sdk/R/DESCRIPTION, update Version:
* services/api/Gemfile to depend on the newly published Arvados gem and run bundle install to update Gemfile.lock
* tools/ansible/roles/arvados_apt/defaults/main.yml update arvados_pin_version
* tools/arvbox/bin/arvbox, update DEFAULT_TAG=X.Y.Z
17 release eng Build final release packages with version "X.Y.Z-1" using the Jenkins job build-and-publish-rc-packages. Add a comment on the release ticket identifying the Git commit hash used for the build, and link to your Jenkins run.
18 release eng Publish stable release arvados/jobs Docker image using docker-jobs-image-release
19 release eng Push packages to stable repos using publish-packages-to-stable-repo (see also https://dev.arvados.org/projects/ops/wiki/Promoting_Packages_to_Stable)
20 release eng Publish Python packages using build-publish-packages-python-ruby
21 release eng Publish Java package using build-java-sdk and following Releasing Java SDK packages
22 release eng Publish R package using build-package-r
23 release eng Publish arvados/arvbox-demo Docker image using build-and-release-arvbox-demo-image
24 release eng Tag the commits in each repo used to build the release in Git. Create an annotated tag (git tag --annotate) with a message like "Release X.Y.Z, release notes at https://arvados.org/release-notes/X.Y.Z/" That makes the GitHub releases page look good. See GitHub documentation for more details about how to automate releases.
Create or fast forward the X.Y-release branch to match X.Y-staging.
Cherry-pick the upgrade notes commit (from step 2) onto main.
25 release eng Ensure new release is published on https://doc.arvados.org/.
Ensure that release notes & any other materials are pointing to correct version of the docs.
(If anything goes wrong, see https://dev.arvados.org/projects/arvados-private/wiki/Docarvadosorg_deployment)
26 ops Update pirca and jutro to stable release
27 product mgr Merge release notes (step 6) from "develop" branch to "main" branch of the arvados-www Git repository and check that the https://arvados.org front page is updated
28 product mgr Send out the release notes via MailChimp, tweet from the Arvados account, announce on the Discourse forum, Matrix, etc.
29 release eng In Jenkins:
* Go to "Job Config History" on developer-run-tests and developer-run-tests-doc-sdk-java-R and record on the release ticket the timestamp of the configuration used to test the release
* Go to Manage Jenkins > Clouds > gce2 > Configure and record the VM image tagged "tests" used for jenkins workers to run the tests for the release (should be something like jenkins-image-arvados-tests-YYYYMMDDHHMMSS) on the release ticket
* Go to https://ci.arvados.org/view/Packer%20Images/job/packer-build-jenkins-image-arvados-tests/ and record on the release ticket the jenkins job used to build the above VM image.
30 release eng Add the release to doi:10.5281/zenodo.6382942
Updating Zenodo Version of Arvados after Release
https://zenodo.org/record/6382943

Updated by Peter Amstutz 9 days ago · 87 revisions