Final Release Tasks in TeamCity.
Not sure how to best achieve the following:
We have our builds and deployments all running from standard templates, which works really well, override a few version numbers, and a source branch, and your new release is good to go.
We run multiple integration cycles until we get a pass from the test team, so build X is our end user release, we don't want to touch or changes those deliverables in any way, they are our signed off release images. What we want to do some tasks in TeamCity like uploading SBOM for that build, copying deliverables to other locations, notifying users by email etc.
We have a plan to do this, however it's currently a bit basic, and requires some manual input of build numbers and works out what to do from that, and copies the deliverables from a network share and it's not linked to the deployment plans themselves. It's quite clunky and potentially fragile I have seen the build approval feature, but that doesn't really fit either.
Is there a better way?
Thanks
Please sign in to leave a comment.
Thanks for the detailed explanation.
From what you've described, your goal is to perform a number of post-release tasks against a build that has already been signed off by the test team, while ensuring the original build artifacts remain unchanged.
A common approach in TeamCity is to keep these post-release activities in a separate build configuration rather than adding them to the original build or deployment. This allows the signed-off build to remain immutable while keeping all follow-up activities fully tracked within TeamCity.
The separate build configuration can use an artifact dependency to retrieve the artifacts from the approved build directly and then perform tasks such as:
•Uploading the SBOM
•Copying deliverables to other locations
•Sending notification emails
This avoids relying on network shares and manual build number entry, while maintaining a clear relationship between the original release build and the post-release actions.
To recommend the best approach, could you clarify one point?
How is a build currently designated as the final approved release?
For example:
•Is there a deployment configuration that is only run after the test team signs off?
•Is the approval handled outside TeamCity?
•Or is there another process that identifies which build becomes the official release?
Approval is handled outside of TeamCity, basically a manual meeting of all stakeholders, with an action to "release" the software once agreement is obtained from all stakeholders.
Deployment is aleady built and digitally signed at this point. Once we are in our integration phase, every build is an integration candidate, and once one of these builds meets the quality threshold, that's it. No more builds.
Thanks for the additional details.
Since the release decision is made outside TeamCity, I'd suggest creating a dedicated Post-Release Tasks build configuration with a snapshot dependency on your deployment configuration and an artifact dependency configured as "Build from the same build chain."
After the approval meeting, simply open the approved integration build in TeamCity, navigate to its build chain, and run the Post-Release Tasks build configuration. TeamCity will automatically resolve the artifact dependency to that exact approved build, so there is no need to manually enter a build number or copy artifacts from a network share.
Within the build, you can reference the original build number using:
I'd also recommend pinning the approved build so it is clearly identified as the official release and protected from cleanup.
This approach allows the signed-off build and its artifacts to remain completely unchanged while keeping all post-release activities, such as uploading the SBOM, copying deliverables, and sending notifications, fully tracked within TeamCity.