Before
Release staff likely had to create the tag from the correct branch, update each customer branch individually, and then search the available deployment pipelines for the right tenant. They also had to start matching pipelines one at a time and manually post progress updates or relay completion status to the requesting team.
How it works
- Receive the release inputs and create a tag from the specified source branch.
- Resolve the tag and update every requested branch to the tagged commit, with a success notification.
- Match customer names to available deployment pipelines, start each matching pipeline, and return status updates.
Workflow details
- Release request intake: The workflow receives a release request containing a tag name, a source branch or list of branches, customer or tenant identifiers, and callback information. These inputs determine which code references are updated and which deployment pipelines are started.
- Release tag creation: It resolves the source branch reference, creates a tag object at the branch head, and publishes the corresponding tag reference. A completion response confirms that the tag has been set on the selected commit.
- Branch alignment: The workflow retrieves the tag reference and updates each listed branch to point to the tag commit. Branches are processed sequentially, and a team notification reports the branches moved to the release tag.
- Tenant pipeline selection: It retrieves the available deployment pipelines, normalizes each customer name by removing supported prefixes and ignoring letter case, and checks whether a matching pipeline exists. When a match is found, the workflow starts that pipeline for the customer; when no match exists, it does not start one.
- Release visibility: The workflow sends channel updates when the tag is created and when customer pipelines are started, including links to the relevant pipeline views. It then returns callback messages describing the tag, branch, or customer pipeline actions that were completed; the pipeline stage is intended to deploy each environment with client-specific parameters.
What changed
The release request now drives tag creation, branch updates, pipeline matching, and pipeline launches as one coordinated sequence. The workflow performs the customer-name validation automatically, skips customers without a matching pipeline, and delivers progress and completion information through the configured channel and callbacks.
Work removed
Manually resolving branch and tag references, creating release tags, updating branches one by one, listing and matching customer pipelines, starting each matching pipeline, posting release updates, and relaying callback status.
Expected outcome
One automated run consolidates at least three recurring release activities—tag creation, branch alignment, and pipeline initiation—while providing consistent status visibility; no measured time-savings or deployment-success metric is specified.
