Skip to content

release.md

Latest commit

 

History

History
61 lines (47 loc) · 5.81 KB

release.md

File metadata and controls

61 lines (47 loc) · 5.81 KB
Raw

Release Process

To facilitate identification of the changes that are released and communication around them, we want to:

  • bump the version number, following semantic versioning. If you want to override the version number, which is automatically determined based on the conventional commit messages being released, you can do so by passing a parameter to the release-it command, e.g.
yarn release-it 1.0.0-rc.1

To make this process easy, we use release-it.

When you're ready to make a release to test and/or prod, apply the following steps:

  1. post in the Teams developers channel that you're doing a release and there's a merge halt on
  2. go into the github settings and turn off merging to develop so no one can merge by accident if they miss the merge halt post. (Optional, but this ensures no other changes are made to the develop branch while the release is in progress. Release PRs can't be rebased (see note below), so if someone does merge something in, you have to restart the release.)
  3. on develop, check migrations against prod data. Ideally, do this using the dag:
    1. Before running the airflow dag, ensure that the test namespace is clear of past migration test deployments. Because failed deployments do not clean up their resources (so that the logs can be checked), this causes subsequent deployments to fail.
    2. To manually clean the namespace from past migration test deployments (after investigating a failure, or before starting a new test), just run the cas_bciers_test_migrations_cleanup DAG.
    3. Go to the cas-airflow-test frontend and trigger the cas_bciers_test_migrations dag. You will need the source (where the database backup originates from, likely abc123-prod) and target (where to deploy the tests, (abc123-test)) namespaces, as well as the git hash of the commit with a backend image built that you want to test (used by BACKEND_IMAGE_TAG).

      [!NOTE] This dag can take 15-25 minutes to complete. There are two tasks that specifically wait 8 minutes and 150 seconds, respectively, to give the pods time to start up before checking for migrations.

    4. Ensure the dag completes successfully. If any steps fail, the helm charts remain deployed in the target namespace for later inspection. If there are any problems with the migrations, create a branch, fix, and merge the fix before continuing.

Warning

There are a few steps to go through before a namespace can be used to test migrations

  1. If the dag is not available, this can be done manually:

    1. in your .env, remove/comment out CHES variables (they should automatically be removed by the script but better safe than sorry)
    2. login to openshift using the command line (openshift docs)
    3. poetry run python manage.py check_migrations_with_prod_data --pod-name {pod_name} (replace {pod_name} with the name of a production Postgres follower pod (in openshift, if you click into the pod, there will be a label that says postgres-operator.crunchydata.com/role=replica)). If there are any problems with the migrations, create a branch, fix, and merge the fix before continuing.

  2. create a chore/release branch and create the upstream

  3. reset database with make reset_db (from cas-registration/bc_obps) for proper creation of migration files

  4. run make release (from cas-registration) and follow the prompts - This will:

    • Create empty migration files for each django app based on the release version
    • bump the version number
    • generate a change log

  5. create a pull request and confirm all the migrations have been created (at the time of writing, one for each of registration, reporting, compliance, common, RLS, and task-scheduler)

  6. once the pull request is approved, if you disabled merging to develop, temporarily re-enable merging so you can merge the release PR, and then disable merging again

  7. go to the shipit dev environment and keep an eye on the required checks on the merge commit (note: check-migrations will fail until #3590 is completed). Once the checks pass, shipit will automatically deploy the release commit to the dev environment once CI passes.

  8. update your local develop branch and fast-forward the main branch using:

- git checkout main
- git merge develop --ff-only
- git push

This will put the release commit onto the main branch, which is connected to the test environment.

  1. go to the shipit test environment and keep an eye on the required checks. Once they pass, you can click the Deploy button.
  2. once the deploy is complete (the logs will show Completed Successfully, usually takes up to 8 minutes), let the team know the release is available in test. Optionally end the merge halt and unlock the develop branch at this point.
  3. tag github tickets with the release version if applicable (see the team_release_process.md for more details)
  4. update the status of the tickets on the board to UAT In Test
  5. once a PO is ready to release to prod, they will typically click the Deploy button themselves.

Do not rebase release PRs. If a release PR falls behind the develop branch, a new PR will need to be created. release-it relies on tags to make comparisons from one release to another. Rebasing makes the tag created during the release process unreachable by git describe, which is what release-it uses to determine the parent tag.