50d8b966d4
* refactor: streamline web release workflow to 2 steps Consolidate the release process from 3 workflows to 2 steps: - Step 1: Create release PR with QA - Step 2: Merge PR (triggers tag, release, build, S3 upload & back-merge) Changes: - Merge web-deploy-production.yml into web-tag-release.yml - Add automatic back-merge to dev after release - Extract only changelog for GitHub release notes - Add prominent warnings about no-squash merge requirement - Update all documentation to reflect new 2-step process Benefits: - Simpler release process (2 steps instead of 3) - Automatic back-merge eliminates manual step - Cleaner GitHub release notes (changelog only) - Reduced risk of human error * security: fix code injection vulnerability in changelog extraction Use environment variable instead of direct interpolation of github.event.pull_request.body to prevent code injection attacks. The PR body is now passed via the 'env' key, which safely escapes any potentially malicious content before it reaches the shell script. Fixes GitHub Advanced Security alert for Code Injection. * feat: add error handling for back-merge conflicts Improvements to back-merge step: - Add continue-on-error: true to prevent workflow failure - Detect merge conflicts and provide clear error messages - Add separate step to report back-merge status - Update Slack notification to indicate back-merge status - Link to troubleshooting documentation when conflicts occur Benefits: - Release process completes successfully even if back-merge fails - Clear guidance for manual conflict resolution - Better visibility of back-merge status in Slack notifications Addresses feedback about lacking error handling for merge conflicts. * fix: remove invalid job-level env reference to steps context The job-level env was referencing steps.version.outputs.version_number, but the steps context is not available when job envs are expanded. This would cause the workflow to fail before any steps run. Fixed by: - Removing the invalid job-level ARCHIVE_NAME env variable - Archive names are already correctly constructed in individual steps using steps.version.outputs.version which is available at step level Validation: - Verified with yamllint (no syntax errors) - Confirmed archive creation steps use correct step-level references --------- Co-authored-by: Hanzo Dev <[email protected]>
2.7 KiB
Releasing to production
⚠️ NOTICE: This document describes the LEGACY manual release process.
For the NEW automated process using GitHub Actions (recommended), see: > 📖 Automated Release Procedure
Legacy Manual Process
The code is being actively developed on the dev branch. Pull requests are made against this branch.
We prepare at least one release every sprint. Sprints are two weeks long.
When it's time to make a release, we "freeze" the code by creating a release branch off of the dev branch. A release PR is created from that branch, and sent to QA.
Preparing a release branch
-
Create a code-freeze branch named
release- If it's a regular release, this branch is typically based off of
dev - For hot fixes, it would be
main+ cherry-picked commits
- If it's a regular release, this branch is typically based off of
-
Bump the version in the
package.jsonas a separate commit with the commit message equal to the exact version -
Create a PR with the list of changes
💡 To generate a quick changelog:
git log origin/main..origin/dev --pretty=format:'* %s'To generate a more structured table layout:
bash ./scripts/release-notes.sh <target branch> <source branch>
git checkout release # switch to the release branch
git fetch --all; git reset --hard origin/dev # sync it with dev
Change the version in app/web/package.json to the new version.
git add .
git commit -m '1.54.0' # where 1.54.0 is the new version
git push
Once pushed:
- Create a PR from
releasetomain. - Add the PR to the Wallet project and set the status to
Ready for QA
QA
- The QA team do regression testing on this branch
- If issues are found, bugfixes are merged into this branch
- Once the QA is done, proceed to the next step
Releasing to production
After the PR is tested and approved by QA:
- Switch to the main branch and make sure it's up to date:
git checkout main
git fetch --all
git reset --hard origin/main
- Pull from the release branch:
git pull origin release
- Push:
git push
A deployment workflow will be triggered and it will do the following things:
- Create a new git tag from the version in
package.json - Create and publish a GitHub release linked to this tag, with a changelog taken from the release PR
- Build production assets
- Upload to S3
- Prepare production deployment
After that, the release manager should:
- Notify devops on Slack and send them the release link to deploy to production
Note: The main branch is automatically back-merged into dev by the workflow