I am attempting to perform Resource Management inside an Azure YAML Pipeline.
The YAML file is checked into source code and can be edited by developers.
Code Reviews will not occur until the deployment is moving from UAT into Production.
I would like to make sure that a deployment to QA cannot perform Resource Management for the resource group associated with the Production Environment. ie: prod databases
Can I limit a Service Connection to only be available in certain release stages?
Is there another way to limit Resource Management to specific stages of a pipeline?
Azure Devops Pipeline Stages: Independent Security
I am afraid there is no such way to limit a Service Connection to only be available in certain release stages at this moment.
According to the document we could to know Service connections:
The service connection security is divided into three categories in the service connections new UI:
User permissions
Pipeline permissions
Project permissions
When your pipeline uses the classic UI mode, you could use User permissions to control who can create, view, use and manage the service connection with user permissions.
If your pipeline is YAML mode, you could use the Pipeline permissions, Pipeline permissions control which YAML pipelines are authorized to use this service connection.
So, there is no such way to limit Resource Management to specific stages of a pipeline.
For this request, you could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
Related
We have an Azure Function and an Azure DevOps Pipeline, the pipeline builds and published the code of the function's repo automatically. We want to escape discrepancies caused by, potentially, people manually publishing a version of the code, from within their Visual Studio, that is not in source control.
How can we ensure that?
Is there a way to disable manual publishing and only allow the Azure DevOps Pipeline to publish code to the function?
I am referring to a person using the "Publish" option in Visual Studio. Is there a way to forbid the Azure function from accepting such a publish?
To stop manual changes to the build, yaml files and pipeline would be to restric access to the build section of the pipeline for all the users.
This way no one will be able to change the pipeline but the admin user will still have access to the pipeline.
To set the permission we have to go to manage security which is under the pipeline tag.
Then we can select the permission for the users.
Here each tag represents a permission. Since we want to stop manual deployment we would set Edit build pipeline and Edit quality pipeline to deny.
These permissions can be set for individuals as well as security group.
Reference:
permissions in devops.
I am looking for some best practices and suggestions:
My team is creating an Azure DevOps pipeline to deploy a complex infrastructure of VNets, VMs, Azure ML workspaces, SQL databases, etc.
The pipeline uses Terraform where possible, but Powershell or AZ CLI where needed.
The pipeline works, it is version controlled, it has proper unit tests and integration tests (or at least decent ones).
However, due to the instability of Azure resourcing sometimes the pipeline will fail because, for instance:
SQL server provisioning fails
AD join of VMs fails
or other activities which are not due to bad Infra as Code, but rather the stochasticity of the task. Provisioning resources is inherently unstable, similar to networking, etc.
I am not complaining about Azure. I am just asking:
How can I adjust the IaC pipeline so that when Azure fails occur, some sort of retry can automatically be triggered?
As a concrete example, is there an Azure or Terraform equivalent to Python's tenacity package or Java's Spring Retry?
How can I adjust the IaC pipeline so that when Azure fails occur, some sort of retry can automatically be triggered?
You could try to use Trigger Azure DevOps Pipeline task to trigger current build pipeline automatically when the build failed.
To be able to use the extension an Azure DevOps API endpoint needs to be created.
For the service connection to work as it should you need to configure the following parameters:
Organization Url: The URL of the organization.
(https://dev.azure.com/[organization])
Personal Access Token: The personal access token.
Besides, we need to set the condition for this task, which will trigger the current pipeline Only when a previous task has failed:
I need to push a DevOps website from azure to IIS on Amazon or Microsoft (or locally).
When I run the script in the Azure VM, I get the error the domain vstsagentpackage.azureedge.net isn't accessible. I assume this is for advanced internal azure networking reasons.
What is the most appropriate way to publish one DevOps site into one IIS Web(app) site while others are running and perhaps managed by others? I'm currently using this approach.
I'm not sure if you have permission to, but if you do, I'd recommend setting up a deployment group or agent (deployment group for classic pipelines, agent for YAML) on the Windows Server hosting the site.
Once you set up a deployment group/agent, you'll want to configure your release pipeline to be set to use the newly registered agent or deployment group within your pipeline.
If you're using a classic (UI) pipeline, you'll want to add a new Deployment Group Job by clicking the ellipsis to the right of your stage name:
After you've added the deployment group job, you'll want to select the deployment group you've just added:
With that configured, you'll be running your pipeline on the IIS server you're deploying to, and you'll just need to add the IISWebAppDeployemntOnMachineGroup#0 task to your release pipeline and point to the site you're deploying to:
I'm using Azure DevOps pipelines and for 'builds' I can define 'Hosted Ubuntu' agent (in my pipelines.yml file). But for 'releases' there's no way to edit yaml just the UI. The agent pool drop down list shows 'Default (no agents)'. I assume my problem is probably related to project permissions but haven't figured out what controls the visibility. On another account I see all the hosted agent options available.
For the possible security permissions issue
Check that you are part of the group(s) assigned as User to the security of the app pool in question.
If this security operates like other Allow, Deny, NotSet permissions, then your occupation in a group that has less than User permission will revoke that permission, but I haven't seen any documentation about this.
For the use of YAML in release pipelines
Yaml usage in the formal release pipeline hub is not supported. If you want to use yaml for your CD release, you're going to need to enable the new multi-stage pipelines experience.
This allows you to create stages in your .yml file that relate to deployment functions in addition to the classic build functions.
I believe this removes your release tracking from the release hub and integrates it directly into the build hub.
This is still a new concept for Azure DevOps, as is the documentation and writing about it. I found this article to be helpful.
Because this new feature seems to be centered around AKS (or other Kubernetes services) and Docker, I'm not sure if this will help you by allowing you to specify the host in yaml, but you mentioned "release" and "yaml" in the same sentence, so I thought I would address that.
I'm in the process of setting out Azure Devops for our organisation and although I have got things working to an extent, I still dont understand a couple of concepts that I think I should.
I have set up a Deployment Pool (Organization settings > Deployment Pools) and used the script to install and configure the Agents on my Dev, Test and Prod servers, and have been successfully able to deploy code to them
I have been able to build my projects using the Azure Hosted option for now, but I would really like to use the locally hosted option, but when looking at the Agent Pools(Organization settings > Agent Pools) I can only see my Production server and it wont let me use that build with. I clicked the button to "Download Agent" but it downloads the agent I already set up in the Deployment Pool stage using the same powershell command .config.cmd command
So as far as I can tell, there is no difference between an agent in an "Agent pool" vs a "Deployment pool", but I'm obviously missing something here as I cannot see the agent in the Agent pool.
Can anyone help me to understand what I might have missed, and why there are two totally different ways of downloading the same agent?
Many thanks!
Deployment pool are for deployment groups are a special agent configuration that are used specifically in release pipelines. They give some additional options for your release pipelines beyond the regular agents.
Deployment groups:
Specify the security context and runtime targets for the agents. As you create a deployment group, you add users and give them appropriate permissions to administer, manage, view, and use the group.
Let you view live logs for each server as a deployment takes place, and download logs for all servers to track your deployments down to individual machines.
Enable you to use machine tags to limit deployment to specific sets of target servers
It leverages the same pipeline agent but you are just specifying different configuration for the initialization. If you navigate to the Agent Pool page, there is a download link there with the configuration for setting up an agent that you can leverage in a build pipeline or in a release pipeline when you use an Agent Phase instead of a Deployment Group phase.