Release Workflow

Purpose: To provide a clear and consistent process for releasing new versions of PermaplanT.

Audience: Maintainers, Release Managers

Status: Draft

Rationale

This workflow documents the release process, including special cases, to ensure that releases are handled consistently and to reduce the size of the release issue template.

Quick Reference

  • Release Issue Template: Refer to the .gitlab/issue_templates/Release.md file.

Workflow Steps

This workflow will be filled out in the future.

Special Cases

Diagnostic Testing

If specific tests fail on staging, use https://master.permaplant.net to diagnose if the issue is infrastructure-related or code-related. This environment runs on production infrastructure and should only be used for diagnosing issues, not for general testing.

Release Fixes

If critical issues are found during the testing phase, they should be fixed directly on the master branch.

  • Apply any critical fixes directly to master branch via MRs.
  • Re-run affected tests on staging after fixes are applied.

Hot-Fix Protocol

If critical production issues are discovered after a release, an immediate hot-fix procedure should be followed.

  • Create a hot-fix branch directly from master: git checkout -b hotfix/vX.X.X+1 master.
  • Apply a minimal fix to the hot-fix branch.
  • Create an emergency MR: hotfix/vX.X.X+1 → master.
  • Merge the emergency MR to master.
  • Deploy the hot-fix to production via Jenkins.
  • Create a new tag: git tag -s vX.X.X+1 <hotfix-commit> -m "vX.X.X+1 - Emergency hot-fix".
  • Communicate the hot-fix to the team.
  • Document the hot-fix in the release notes.

Examples

  • Release Issue Template: .gitlab/issue_templates/Release.md

Troubleshooting

Open Points

Notes