Change Release Workflow Automatically

[William Graber]

Hello. I'm trying to setup a two-stage deployment scenario. Stage 1 is triggered automatically at a certain time, and runs through an application setup and deployment. That is working fine. However, once that happens, I want to be able to push out hotfixes triggered by SCM commits.

The current setup looks something like:
<code>
Release
|-Deployment Workflow
| |-Deployment Build
|
|-HotFix Workflow
|-HotFix Build
</code>

A release is made, a deployment build is triggered, executed, and then finishes. The release remains active, but is stuck in the Deployment Workflow. This means that the HotFix Build cannot be triggered, because the release is in the wrong workflow.

If I manually switch the release's workflow to the HotFix Workflow, SCM triggered hotfixes work as intended. However, as far as I can tell, there's no way to automatically change a release's workflow.

Creating a new release for the hotfixes isn't really an option. I could make a new application specifically for hotfix deployments, and do it that way, but that seems to defeat the entire point of workflows. (Not to mention being a pain.)

Any ideas?

Product: BuildMaster
Version: 4.9.7

[Alana]

Would you be able to create a separate release for the hotfix scenario?

The idea is, a release is what follows the workflow (pipeline) to production.

[William Graber]

No, as I mentioned, making a new release specifically for the hotfixes isn't really an option. It would require major reworking of the release cycle, not only in BuildMaster, but in our project tracker and the application itself as well. Various components rely on the synchronicity of version numbers, which are tied to release numbers in BuildMaster. Making a new release outside of the normal version cycle would break everything.

It is feasible to switch the release numbering to date based, and then track (and modify) the version number via a variable, but that would mean adding a ton of functionality to the workflows in order to reproduce something that BuildMaster is currently doing autonomously. Honestly, I'd rather make a new application solely for hotfixes. Either way, it's not going to be a simple solution, whereas having a means of promoting a release to a new workflow would require almost no changes to existing build processes.

[William Graber]

I've managed to implement this using the BuildMaster API.

The combined workflow now looks something like:

Saturday 9:00PM (Prior status):

Release 1: Hotfix Workflow
Release 2: Deployment Workflow - Pre-Staging

Saturday 10:00PM (Latest Release Deployed):

Release 1: Marked as Deployed
Release 2: Deployment Workflow - Deployed

Saturday 10:30PM (New Release Created):

Release 2: Deployment Workflow - Promotion
Release 3: Deployment Workflow (No Build)

Saturday 11:00PM (Automatic Build Triggers):

Release 2: Hotfix Workflow
Release 3: Deployment Workflow - Pre-Staging

One of the steps executed during the Pre-Staging workflow (initiated as soon as a build is created) is to call a script which uses the API to first reject any active builds from the previous release, and then update the release with the new workflow.

API Steps:

1. Get Builds for previous release with Builds_GetBuilds.
2. Check for any builds with Current_ExecutionStatus_Name == "Executing", fail if there are.
3. Reject all builds with BuildStatus_Name == "Active", using Builds_RejectBuild
4. Update Release with Releases_CreateOrUpdateRelease, setting the desired Workflow_Id.