In addition to the hierarchical permission model for folders and projects, FlexDeploy supports a hierarchical permission model for releases. Default permissions can be set on the root folder for the entire hierarchy.
| Tip |
|---|
|
Overriding Security
To override the security permissions, first open a folder or release by clicking on it, then click on the Security tab.
Click the Override Security button to override the permissions of the parent folder.
From the folder view, the Release permissions are located underneath the Folders/Project permissions. Select the permissions you wish to grant for any particular groups.
You can click on the input to see the full list of groups as well as begin typing the name of a specific group to add.
Click on the group to add it.
Click the Save button to save any changes. If you decide to inherit permissions from parent again, then toggle Override Security off and click Save.
The table below provides a summary of the permissions for Releases.
Permission | Description |
|---|---|
Read | Release (collection of projects for specific delivery) can be read. Release permissions can be overridden for individual Releases as well. Read permission is granted to users that receive write permissions. |
Update | Release can be updated. |
Create Snapshot | Create snapshot is allowed. Create snapshot is process of including build version(s) into a release. |
Configure Content | Projects/packages and work items can be added or removed from release. |
Configure Pipeline | Pipeline can be configured on release with this permission. Access to Override members on Teams tab is also controlled by this permission. |
Manage Lifecycle | Release start, pause, end actions are allowed. |
Comment | Adding comments to the release is allowed. |
Grant Permissions | Release permissions can be managed for individual releases, otherwise only Admin Group users can configure permissions. |
| Tip |
|---|
The FlexDeploy permission model offers great flexibility for managing security. However, you must understand that with fine-grained security comes the overhead of needing to configure and maintain it. You should avoid managing permissions at a level lower than you really need. For example, if you choose to manage all security at the individual project level, you will need to configure the security every time you create a new project. Instead, if you establish permissions near the top of the folder hierarchy, you will only need to configure security when you create new high-level folders or when your security requirements change. |