" + new deployment plan " link missing

[tdallmann]

I am trying to set up group permissions to allow members to create a new deployment plan, but then only give them access to deploy to specific environments.  The specific environment part is easy, but I cannot figure out how to get the New Deployment Plan link to display without giving them access to everything.  Is there something I am missing? 

 

User group - imported from LDAP (AD)

Type = user, artifacts manager

For Application Structure:

- can view Application

- Can view design components

- Can view Execution Components

For the Environment:

- Environment Admin

 

I have also selected the server group for the environment.

 

What permission do I need to get this link to appear?

[Michael Gebhardt]

did you try giving them the "Release Template Designer" permission?

[James Panetti]

I second Michael's suggestion -- It sounds like template-specific permissions would be the next to look at, and make sure it's checked for this user/group.

[James Panetti]

HI there -- were you able to sort this out with our suggestions, or is it still a problem?

[tdallmann]

I set Michael's answer as correct, since it did work, though I would like it if we could allow someone to create a new deployment plan without "Release Template Designer" permissions. 

 

Thanks fr the help all!!

[James Panetti]

I do not believe it is presently possible -- I tried a few scenarios on a test environment, and I'm fairly sure template designer permission is required, since deployment plans are built off of templates.

 

I can see the reasoning for expecting otherwise though -- I recommend submitting an idea here in the Communities for adding deployment plan level permissions.  I think that would be very much worth considering.

[Chip Rabinowitz]

JamesPanetti, I'm a little confused here.  Doesn't the Jenkins plugin call "RunDeploymentPlan" to execute a deployment?  This means that developers are required to have Template Designer permissions in ALL cases?  That doesn't make sense given that the continuous delivery workflow starts when the developer runs a build.

 

Or are the Release Managers expected to create a Deployment Plan, then the developers assign a package once they have a build?  I just don't understand how the workflow is supposed to operate here.....

Can you (or PM) explain this to me?

[Michael Gebhardt]

from where does jenkins comes into play? wasn't part of the question

 

but anyway, we're not using jenkins yet, but I assume the set up is transferable from creating a plan/deployment after a tfs build (we're using our own WCF instead of the tfs plugin, but the plugin will most likely use the same REST calls). to do that you need to specify a user for the rest call, only this user has the required rights in CA-RA. I would think that this is the same for the jenkins plugin and it just uses some service account that runs jenkins? or does the jenkins plugin uses the user that started the build to do stuff in CA-RA?

[Chip Rabinowitz]

I brought up Jenkins as an example off the "full" workflow that starts at the developer.

 

Yes, you can use a service user to kick off the deployment....but then how do you track the "who" deployed?  All your reports will just show the service account?

 

I guess the front-end (your WCF, Jenkins, whatever app does the deployment) could use a service account to create the deployment plan, then the executing user to start the deployment, but this seems unnecessarily complicated to me....

[Michael Gebhardt]

it is not complicated at all, we're giving the dev guys the opperunity to set up either an auto-deployment to a dev environment or they simply create the plan and do the deployments themselfs.

 

both ways still allow tracking of the user who did it, because the one who triggers an autodeploy after build, is the person who started the build (yes the deployment just shows a service account, but if you really want to know it, check the build). if it is a nightyl build-deploy process, well, then it is a service account who did start the build and deployment, but everyone knows about it.

 

either way, we're limiting autodeployments to dev environments, so it wouldn't even really matter to know who did it

[James Panetti]

I am not a subject matter expert in Jenkins myself, but I will poke someone who is so I can get an answer for you.

 

My tests were done strictly through the ASAP and ROC GUIs.

[Saurabh Jain]

Please find some inputs from my end.

I will be using below acronym:

RTD - Release Template Designer

DP - Deployment Plan

1: Permission “Release Template Designer” controls permission over  various aspect/features of product i.e. whether a user can create Templates, Deployment Project, Deployment Plans or not. As the name suggest it make him a Designer of a Release and henceforth with this permission a user can access all features required by him to create or modify a release.

 

 

There was a question why we need to give a "Jenkins user - A users used in Jenkins build step"  RTD permission to create a release. This is most obvious question especially if you have been using Jenkins to run process in 4.7  To have a clear understanding of this we need to understand the maturity product had undergone from 4.7 to 5.5. In 4.7 stage there were just two features "Template & Release", there were not a mature concept of "Release Designing" which was introduced in 5.5, where a release designer can now design the actual blue print of a release i.e. a deployment plan. So in 4.7.1 a user without RTD permission can create releases (which can also be achieved in 5.5 in slightly tweaked manner) but in 5.5. you need user to have RTD permission if you want to create DP with each build triggered via Jenkins.

 

 

2: I will try to explain what I explained above can a user in 5.5 without RTD permission can create releases? Answer to this is yes. If you want to run in same fashion where you don't want this user to do any task of a release designer he can go ahead and create releases with existing DP's. In this manner the system work in similar fashion that of 4.7 where releases are getting created with existing blueprints. The Jenkins plugin of RA has 3 option for its parameter "Deployment Plan usage methods", which are listed below.

 Create new deployment plan everytime

 Create new deployment plan once and use it everytime

 Use an existing deployment plan

 

 

For first two options you need user to have RTD permission for the last option you don't need RTD permission and it will be using existing blueprints i.e. DP. The permission set required with 3rd option for a user to create release will be 

a. Application Level: Can View Application

b. Environment Level: Release Designer, Can Execute All Releases

 

 

3: With above mentioned it is very visible the Jenkins plugin uses two REST API's depending upon the option selected for "Deployment Plan Usage method", which are below.

run-deployments: Creates a deployment from an existing deployment plan. User can create, or run the deployment on the environments provided

run-deployment-plan: Creates a deployment plan from an existing deployment template.

 

 

4: If you want to audit who is the creator to deployment plan and who is the executor of release there are two places to trace that. Who is making changes to system are considered as "Audit History" which keep track of all the changes been made in system by each user. You can configure the dashboard -> Audit history report to trace what changes been made by user for example it will record which user created the DP. To know the user who run the release you can just open the specific release and it will be having that information under "Executer".

 

 

I hope above will be of help.