ci: 👷 Prevent Releasing New Versions During a Freeze Period

[karlbaumhauer]

User Story

As a release manager, I want to block the creation of new releases during a designated freeze period, so that I can ensure the stability of the production environment during critical times like holidays.

Background Information

During critical timeframes, such as the holiday season, there is a need to enforce a “release freeze” to prevent new versions of the software from being deployed to production. While development and merging activities may continue, the creation of new releases (e.g., tagging a version or triggering a release pipeline) should be restricted during the freeze period. This ensures stability and minimizes the risk of introducing changes that could disrupt operations during high-stakes periods.

Acceptance Criteria:

1. Release Freeze Enforcement:
   1. Creation of new releases (e.g., GitHub tags, version tags, or initiating release pipelines) is blocked during the specified freeze period.
   2. The freeze period is configurable in the workflow.
2. Developer Feedback:
   1. Attempts to create a new release during the freeze period result in a clear failure message indicating the freeze is active.
3. Logging:
   1. The workflow logs details of the attempted release, including the time and user who initiated it.
   2. Developers can see why their release action was blocked.
4. Outside Freeze Period:
   1. Release actions proceed as usual when the freeze period is not active.
5. Flexibility for Exceptions:
   1. Repository admins can bypass the release freeze for critical fixes or emergency deployments, if necessary.

Notes:

• This functionality applies to release actions, such as creating a release through GitHub’s UI, tagging a version via Git, or triggering deployment pipelines.
• The freeze period should be documented and communicated to all team members.
• Exceptions to the freeze should be explicitly approved and documented by @yoezlem or @karlbaumhauer .

Environment (GitHub Actions or Azure DevOps)

GitHub

Technical Information

DoR

• [x] Item has business value
• [ ] Item has been estimated by the team
• [ ] Item is clear and well-defined
• [ ] Item dependencies have been identified

DoD

• [ ] Documentation has been created/updated (if applicable)
• [ ] Implementation works successfully on feature branch

[mariohamann]

Looking at this image, there are several things to consider.

Deployment targets

1. CDN: Only the wildcard URLs are an issue, everything else is pointing to a specific version, which is a safe case. In general we state in the docs, that they shouldn't be used in production environments, but as Karl said: We never know. Personally I see it as the project using wildcards versions as violating the freeze period, but whatever.
2. NPM: I definitely don't see NPM as an issue, even when people use Renovate or any other tool: They have to ensure, that things are not automatically deployed as actually the update of any other package could trigger a new release.

Possible solution points

1. Prevent merges on main: This could be done by either a check (which possibly could be bypassed, e. g. by overriding actions). Another solution would be to set "Lock branch" in the branch protection rules, which would be a lot safer and can be easily toggled without any code changes. This is definitely the most strict variant, BUT feels the most invasive on the workflow, as people possibly couldn't finish stuff. In addition even security relevant updates from our own Renovate couldn't be published.
2. Prevent releases after merge on main: This wouldn't change anything on the team's workflow. The downside is, that when we reactive releases, there would be possibly a bigger release with all changes at once. I personally don't see an issue here, especially as we don't have to expect like 20 relevant changes or so in that time. Instead of hard coding dates into the action, I would go more with a GitHub Actions Variable for our Repo instead, which could be toggled then, so we can re-use for the next year again without any code changes.
3. Prevent push to Azure: As written above, NPM publishs shouldn't become an issue. Therefore we could just prevent publishing to Azure, which therefore wouldn't trigger anything on Azure side. Actually we could just deactive the whole pipeline for that side, so that nothing can happen there. Unfortunately this would lead to versions being available on NPM, but not on the CDN, which can lead to confusion, as the docs wouldn't be up-to-date and specific versions wouldn't be reachable.
4. Prevent updating wildcard versions: This would be the least invasive change: We could just block releasing the wildcard versions and instead just publish the rest. This would have to be clearly communicated, so that people do not expect to get updates on the wildcard URLs in that time. Furthermore this could lead to the fact that some wildcard versions will not their possible final version number. To be honest: As the wildcards should never be used in production, I don't see this as a problem. I would use this with an Azure variable as well, so that this can be re-used without further code change in future.

Personally I would go with 2 or 4.

• 4 would be the best for being able to still provide updates (e. g. security ones) and doesn't change anything in our current processes. Furthermore it's very far away from GitHub, where most of our team works, which makes it more stable as well. Still it needs a little communication regarding "no updates on wildcard URLs*.
• 2 doesn't block the current process of merging, but just prevents releases completely. It just leads to a bit of bigger changelog in the end. I see this as an okay-ish compromise between clearness towards our stakeholders and not changing our workflow. But: It would even prevent things, if there's something security relevant.