diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 05a0ad5..29bbda6 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -2,10 +2,10 @@ exclude: "^.venv$|^.cache$|^.pytest_cache$" fail_fast: false default_language_version: - python: python3.11 + python: python3.10 repos: - repo: https://github.com/pre-commit/pre-commit-hooks - rev: v4.2.0 + rev: v4.6.0 hooks: - id: check-added-large-files args: ["--maxkb=1024"] @@ -21,20 +21,26 @@ repos: - id: debug-statements # NOTE: Keep order as pyupgrade (will update code) then pycln (remove unused imports), then isort (sort them) and black (final formatting) - repo: https://github.com/asottile/pyupgrade - rev: v2.34.0 + rev: v3.17.0 hooks: - id: pyupgrade args: - "--py39-plus" name: upgrade code + - repo: https://github.com/hadialqattan/pycln + rev: v2.4.0 + hooks: + - id: pycln + args: [--all, --expand-stars] + name: prune imports - repo: https://github.com/PyCQA/isort - rev: 5.12.0 + rev: 5.13.2 hooks: - id: isort args: ["--profile", "black"] name: sort imports - repo: https://github.com/psf/black - rev: 22.3.0 + rev: 24.8.0 hooks: - id: black name: black format code diff --git a/release-notes/README.md b/release-notes/README.md new file mode 100644 index 0000000..f74c7e2 --- /dev/null +++ b/release-notes/README.md @@ -0,0 +1,118 @@ +# README + +### TL;DR +- This folder contains **release notes** divided by **product**. +- They must be **comprehended by any user** of the platform/product. +- Scrum master orchestrates their process of creation. + +## How is this content created? + +All **release notes** are created using an iterative approach involving members of multiple teams: developers, App Team, product owners. + +The process is coordinated by the current scrum master. They are responsible for coordinating the team effort and making sure everything is in place before the release. + + +## Scrum master procedures + +The scrum master takes care of enforcing deadlines. Their goal is to produce an email sent to the App Team containing information about: +- where, when and what to test +- ask App Team to rewrite the `draft release notes` into user readable `release notes` + +The following procedure is suggested (more details below): + +1. ask PO(s) (Nik) for the next review date. Be insistent. I mean it: **BE INSISTENT!** +1. coordinate with team when to deploy to `staging` and `production` +1. once dates are available create the **deadlines calendar** and post it to the team on Mattermost (reminders about important deadlines) +1. ask developers to fill out the release drafts per product +1. ensure NIH Staging is properly deployed +1. inform App Team after the review when the deployment is ready for testing +1. ensure all drafts have been converted to a non draft form (including the rewording) before release + +### 1. `review date` + +Ask Nik (be insistent) for the review date as soon as possible. +It is impossible to organise without a release date. + +### 2. `pick staging and production release dates` + +Ask team members if it is possible to release to: +- `staging` 1 day before the review +- `production` after the App Team finishes testing staging (usually one or two days after) + +### 3. `deadlines calendar` + +The following deadlines must be established (pass them in this order to the below cli): + +- `prs_merge` (pull requests merge date) `usually one day before release to staging`: users have to get PRs (which must be testes by the App Team) merged in master by the end of this day +- `staging_release` (staging release date) `decided with team`: PRs are moved to staging environment to which App Team will have access +- `review_meeting` (review date) `decide by PO(s)`: the day of the review provided by Nik +- `start_app_team` (first day of testing) `first day after review`: this day (included) App Team will have exclusive access to the NIH Staging deployment +- `end_app_team` (last day of testing) `second day after review`: this day (included) by the end of the day App Team will be done testing +- `prod_release` (production release) `decided with team`: staging changes are moved to production on this day + +```shell +python scripts/3_deadlines_calendar.py +``` +- `` format: `dd.mm` where `dd` is a valid calendar day and `mm` is valid calendar month + +**NOTE:** make sure to enforce important deadlines (1/2 days before they expire) like: +- date and time when `all PRs` need to be `merged` before release to staging +- date and time when `release drafts` need to be `completed` + + +### 4. `release drafts compilation` + +Ideally these are done before the review. The App Team will most likely see them only during testing. +The email to the App Team should be sent briefly after the review is over. + +Use the following script to generate the new release drafts for all the products. +A Mattermost message is also provided. + +:warning: Do not forget to commit and push the changes in the repository! :rotating_light: + +```shell +python scripts/4_make_release_drafts.py