Ideally, bleeding edge commits (HEAD) are deployed to staging (dev) and tagged releases are deployed to prod.
Unfortunately there is no approval workflow for tag creation (in the git host yet), but we still want to reduce barriers to rapid testing cycles in the non-prod environment.
A prototype CI/CD pipeline proposes PRs that will sync a stable branch with the current main branch. FluxCD for prod can track stable instead of tracking tags.
Proposal
The PR message should summarise:
What new commits will be promoted.
What hotfixes will be undone (to unwind divergence).
How many other irrelevant commits are being carried over (which only impact the dev environment, not the prod environment nor the shared modules).
Should also update the PR title (to include the change count, or at least a version number).
Could also consider whether there is an alternative to having double merge commits. (Can't just fast-forward because we need at least one dual-parent commit to tie the two separate histories. Having a dual parent commit in the feature branch lets us get a sane list of commits in the PR. But also having a PR merge commit gives an opportunity to record metadata such as the approvers and promotion timestamp. So an alternative would likely have to replace the git hosting provider's merge machinery..)
Ideally, bleeding edge commits (HEAD) are deployed to staging (dev) and tagged releases are deployed to prod.
Unfortunately there is no approval workflow for tag creation (in the git host yet), but we still want to reduce barriers to rapid testing cycles in the non-prod environment.
A prototype CI/CD pipeline proposes PRs that will sync a stable branch with the current main branch. FluxCD for prod can track stable instead of tracking tags.
Proposal
The PR message should summarise:
Should also update the PR title (to include the change count, or at least a version number).
Could also consider whether there is an alternative to having double merge commits. (Can't just fast-forward because we need at least one dual-parent commit to tie the two separate histories. Having a dual parent commit in the feature branch lets us get a sane list of commits in the PR. But also having a PR merge commit gives an opportunity to record metadata such as the approvers and promotion timestamp. So an alternative would likely have to replace the git hosting provider's merge machinery..)