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.
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 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.
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.
Is it possible to disable user-level credential deployment in a particular App Service Plan?
In a development environment deploying directly to the AppService is fine, however a production environment should require more gates e.g. via a release pipeline.
User-level credentials are shared across an entire azure account, is it possible to disable them for production?
The portal indicates the ability to disable ftp, but it doesn't suggest this covers deployments in general.
Is it possible to disable app-level credentials as well? I'm wary of it's audit-ability not being tied to an individual user.
EDIT:
The release pipeline is currently using the MSDeploy extension within an ARM template. For this app we're currently not using deployment slots, but that's a good point we would use them for other applications.
Unfortunately, no at this moment. As long as the user is a contributor to the site, he/she will be able to browse to the relevant SCM site (meaning making changes/deployment). Similarly, for app-level cred. Could you clarify what type of cred is being used to do release pipeline? Does it mean deploy to slot and swap is the only mean of deployment?
What I want to accomplish:
I want to deploy an Azure Cloud Service via Release Management. I managed to get this working by following the steps outlined in this post. In the post the Azure publishsettings file is added to the project and used in Release Management to deploy the Azure package to a Cloud Service. So far so good.
What is the issue:
The Azure publishsettings file will also contain information about the production environment. I don't want that information to be available to all the developers and therefor I would like to have a more secure alternative.
What did I try:
I created a custom action which takes 3 arguments: subscription id, subscription name and certificate key. This way the Azure information stays in Release Management and can be passed to a script. This didn't work because the action is not shown in the Release Template Toolbox.
What is my question:
What is the best way to pass Azure credentials to a deployment script via Release Management on a secure manner?
We have a solution for Build today that will work for RM in the future.
Publish Settings file is an important one with which anybody can get access to certain activities. And once how ever the way you pass on the publish settings file, it can be misused (if tried).
So along with the publish settings file, you need to add a bit of process to the deployment like -
Inactive or remove the management certificate which will in turn invalidate the given publish settings and anyone should request for a new set of publish settings file before they actually start any release procedures.
Even though it adds a rough edge to your smooth flow of deployment process, as it is a live or production system, it is always better to tight the process and make it idiot proof.