I want to use Library Varibles as Azure Deployement Group name in Azure Dev-Ops Release pipelines , is it possible ? And Is it a good practise to do it ?
Purpose : I want to use same pipeline and same stage to deploy on different environments , so that If I change Deployment Group Name (Dev,QA,UAT) in library variable , it will deploy to that env.
I am afraid that the Deployment Group name field doesn't support to use Pipeline Variable(e.g. Library Variable) to define the name.
It currently only supports hard-coded deployment group name in Deployment Group job.
For a workaround, you can add multiple deployment group jobs with different deployment group name. Then you can set the condition to determine which job can run
based on the Library variable value.
Here is an example:
On the other hand, I can fully understand your requirement, I suggest that you can create a suggestion ticket in the Developer Community.
Related
I have a Azure Pipeline to create alerts in Azure. So in pipeline task I am using the AzureResourceGroupDeployment task and where I gave option to define the deployment name. My requirement is to create alerts timely basis when needed and using a sample alertquert deployment template and parameters.json where the parameters values will be replaced with each time when pipeline triggered for creating the alerts with different input values using runtime parameter ad the parameters.json will be updated accordingly.
So here I am not sure about the deployment name, as whether I have to specify the deployment name differently in each time when I create different alerts or, I can have the same deployment name itself?
If i create the alerts with same deployment name for with different alerts names, whether this will delete or modify the previously created alerts using the same deployment ?
Also if I want to update the alerts which is already created, whether I can update it by using the ame deployment name and same alert name?
The resource group keeps a record of deployment events; the information stored includes the parameters input, the resources created, and any outputs.
Each record is identified by a name; that's what the deployment name is.
This history of deployment events is accessible in the azure portal, and also through az cli and azure powershell.
It's up to you whether you want to reuse a deployment name again, or use unique names (e.g. by adding a datetime suffix). If you reuse a name in a future deployment then the previous record will be overwritten; so you lose your history a bit, but it means that the deployment events record is quite tidy, holding only the most recent deployment record for each resource.
If you prefer to use new unique deployment names each time, then you get the advantage of having a fuller history; but there is a limit of 800 deployments per resource group and if you reach it then you cannot deploy anything until you delete some records.
Let say I have 2 Deployment Groups Named QC and Production, each one contains X number of servers.
I also have a Release Pipeline with 2 stages QCStage,ProductionStage.
How can I set my permissions,on Deployment Group Level, so that users can't deploy to Production?
I can achieve this using "Pre-deployment approvals" on each stage but I have hundreds of Pipelines,
we can't be setting permissions for every stage for every pipeline
Update:
This doesn't see to be supported on Azure DevOps,a new Feature Suggestion has been created:
Prevent users from deploying to a Deployment group using Deployment Group Permissions (not on each Stage)
How prevent users from deploying to a Deployment group
Answering this question at two different scope levels.
Scope 1:
Take a simple sample, there has 2 deployment groups in your project: QA and Product.
If what you want is some of users can deploy to QA but not Product, I'm afraid this hasn't been expanded into azure devops until now.
Now for azure devops service, we provide 3 permission level controlled: collection, project and object. Deployment group is the one which belong to object level permission. We haven't provided more granular permissions control, like setting permission on one specific deployment group at this scenario.
Scope 2:
Just restrict someone to deploy a release.
As you know, Deployment group are used for a release stage. In this scenario, in order to control who can/can't deploy a release, please use the release permissions. BUT, there has one disadvantage that it work only for manually initiated releases.
So, I'm afraid Approvals on release stage is another and better option for you to make use until now.
I currently have a release pipeline with a number of stages. In the Deployment group job I have to specify Deployment group (which is fine), but in order to run my pipeline on a specific VM(agent) in that group I also have to specify some tags to limit the number of matching targets.
Instead of using tags in the Deployment group job I would like to use a variable to specify which VM(agent) to use. This variable can then be set when the release is created. Is this something that can be achieved in some way?
I think that the only way to do this would be through Agent capabilities.
In self-hosted agents a capability is:
Capabilities are name-value pairs that are either automatically
discovered by the agent software, in which case they are called system
capabilities, or those that you define, in which case they are called
user capabilities.
Under your Agent pools if you select your agent you will discover a tab Capabilities.
For self-hosted, you could determine a user-defined capability. These means to have a capability you will later check during release time.
How could you provide that info? In your YAML you will specify:
pool:
name: Default
demands: SpecialSoftware # Check if SpecialSoftware capability exists
What this will do is only agents that meet those capabilities will be suitable to perform the deploy
And remember this if anyone finds this answer, for Microsoft hosted agents:
Demands and capabilities apply only to self-hosted agents. When using
Microsoft-hosted agents, you select an image for the hosted agent. You
cannot use capabilities with hosted agents.
I'm trying to re-use a Deployment Group Job and execute it for each member of a ClientID list, but it is not working. The name of the stage will also be used in my tasks.
As described on this page...
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=classic
I've create two variables:
ClientID
client1, client2, client3
Multipliers
ClientID
The stage only has a Deployment Group Job and not an Agent Job because after the deploy I have tasks to run on the self-hosted servers. I need to stop and remove a service, copy files, register and restart a service.
There are no other options on the Stage or the Deployment Group Job for multipliers. (There is the "multiple" options for parallel deployments to servers within the group but that is unrelated as far as I know.)
If I add an Agent Job then I can see that it has the "Multi-configuration" and "Multipliers" options that other articles mention. On a deploy the agent job executes multiple times as expected but not the deployment group job.
The article above talks about "Multi-configuration deployments", so I'm I wrong to think the Deployment Group Job should work that way?
Any help is appreciated. Thanks.
I am afraid that using multipliers in the deployment groups is not feasible.
According to the definition of Multi-configuration in the agent job : each configuration will use a single agent.
But, in effect, a deployment group is just another grouping of agents, much like an agent pool.It could not assign a single agent to each configuration.
So I think that multipliers are not available in the deployment groups.If you want to use multipliers, then you need to use agent job.
Can deployment groups be searched for a particular machine? I need a way to find if a server is already part of a deployment group. I can't tell from the group names if they are applicable to the project.
You could use the REST API for Deployment Groups and look in the Machines property.
Or, if you have access, you can open the deployment groups navigation and look at the targets.
You may want to employ a more robust implementation of tags for the machines in your deployment groups, so you know you'll only deploy to machines in the group that are applicable.
You could simply use Rest API to list all deployment groups in a specific team project.
GET https://dev.azure.com/fabrikam/{project}/_apis/distributedtask/deploymentgroups?api-version=5.0-preview.1
Conversely, it's not able to list all target groups for a special machine at present.
As a workaround, you can add a tag to a machine on the depoyment group configuration.
After that, specify the tag at the release deployment group phase.
This will make the release to choose all machine within the group deployment that match you tag.