Search code examples
ms-release-management

Does the "Can Trigger a Release from a Build" feature of Release Template ignore security settings?

For compliance reasons I have to make sure a release from a certain Release Template can only be initiated by a dedicated user. In my situation the user who is entitled to start a release is a service user, part of the automated Change Management process, while the user who can prepare and define deployment steps is a different one, a real user.

I was able to configure Release Manager in a way when I could separate these roles. User A can manage servers, create environments, release paths as well as release templates and set security. User B can define release steps in a release template using objects created by user A. Since User B does not have the right to manage security this way it is possible to ensure that the Release is executed by only user C.

However, the problem comes when the "Can Trigger a Release from a Build" feature is turned on in a Release Template. When it is turned and "Release Build" parameter is to True in the Process section of the build template then the security settings of the Release Template are ignored and anybody who has a user in Release Management, even without any permission, can start a Release from a build.

For me it looks like no permission checking is performed when a release is initiated from a build by a build agent except for checking whether the user who has started the build also exists in Release Management.

I am looking for a way to ensure that a Release can be started ONLY by a dedicated user while other user has the permission to define release steps of the same Release Template. I might have miss configured something but at this moment it seems to be impossible to set it this way in Release Management. I would appreciate any help if somebody already managed to set it.

Solution

  • Yes, of course it does. If you have a build tied to a release template with that option enabled, you're essentially saying "I want this build released after it's done building, every time." It wouldn't make sense for the build to sometimes be released and sometimes not, because that violates the devops golden rule of "consistency".

    I'd say this is a weird requirement, as you already have the ability to gate your releases behind approvals.

    Some options:

    • Add a "dummy" first stage to your release, so your release path is something like PreApproval -> Dev -> QA -> Staging -> Prod. Set all of the steps in PreApproval to "Automated", then add an approver who can approve the build to be deployed to dev.
    • Release the build manually.