I would like to know if the same on-prem machine can be used as both a build agent and a deployment agent. Is there any documentation that reference this?
While we typically try to keep our private build and release agents separate, there is nothing stopping you from doing both with one agent. Just make sure to pick Agent Pools (read, manage) and Deployment group (read, manage) when generating your PAT for the agent.
If they are separate agents on the same machine, then that will work too. We are doing that now.
Related
Context
I'm deploying multiple apps using Azure Pipelines to app dedicated namespace in a single AKS cluster.
Problem
Since my ADO Environments is assigned to a single AKS cluster, and when I add Approvals and cheks for that environment, then every Deployment that points to that environment will need approval. This is problematic when you deploy multiple apps per environment because all deployments will be guarded by this policy.
Question
Besides of creating approvals for Environment per app. Is there a way of setting up a granularity of approvals within ADO Environments?
Short Answer
"No". At the moment of writing this answer, an environment in DevOps supports only one approval -maybe it will change in the future.
Solution
There is a workaround for this problem. You can set approvals for individual service connection instead.
When you deploy an application to an individual namespace, a service connection is automatically created for that namespace. It might look like this <aks-cluster-name>-<k8s-namespace>-<long-intiger-id> e.g. my-aks-dev-we-sandbox-1654784698962. You just need to find this service connection in ADO's Project settings, click it, and then click on three dots (located in right upper corner) and choose Approvals and checks. This way, you will be able to control who should do the approvals.
I have to configure the CI/CD pipelines for 2 web applications hosted in On-Premise environments & those web applications have multiple platforms (i.e. Dev, Test, QA & Prod). Both are .net applications. On-premise application source code was located on TFVC & recently have been migrated to Azure DevOps (Git).
Now, next step is to build the CI/CD pipelines for these applications. Also, other projects which are already on Azure DevOps, as per customer security standards, Agent pools are being used for build pipelines & Deployment pools/Deployment groups are used for release pipelines & hence we would need to go by the similar approach to build the CI/CD pipeline for 2 applications. Customer would like to use existing deployment pool to be used for rest 2 applications as well. Hence no need to build deployment pools so existing deployment pool could cater to multiple projects. How to achieve it?
Now, looking at the existing configuration of Agent Pools in Azure DevOps, we see that they are using Build Agent hosted in On-premise (TFS server itself) & is being used for building code for few projects.
Can same TFS server i.e. Build Agent could be used for other projects as well? Do we need to install Build agent again onto that server & run commands?
How about release pipeline? I assume, we need to build multiple stages for the release to happen.
Can someone explain step by step process please? I am not from development background & hence struggling a little bit.
You donot need to create new build agents or deployment pools for another projects in the same organization.
You can using the existing build agent pools and deployment pools in multiple projects by following below steps.
Go to project settings of the other project-->Agent pools under Pipelines-->Add Pool-->Existing-->Select an existing pool
Then the two projects can share the same build agents in the same agent pool.
Adding deployment pools to other project is simple too. See below:
In the portal of the other project-->Go the Deployment groups in Pipelines section-->go to Available pools tab-->Click the plus "+" to add the existing deployment pool to this project.
Then the release pipelines of both projects can target the same deployment pool.
Update:
If you cannot adding the existiong agent pool. You probably donot have the permission. You need to ask the administrator to add you as the reader. See below steps:
Go to the Organization Setting-->Agent pools under Pipelines-->Select the agent pool you want add to another project-->Go to Security Tab-->Add your account as Reader.
We have Azure Build and Releases pipelines for our App Service. Everything is pretty straight-forward.
We initially configured single instance for the App Service and Release pipeline worked great.
But after scaling it out to 3 instances what we learned was that release pipeline delivers artifact only to one of 3 instances
So, the question is, how we can configure it in a way so artifact is deployed to all instances of the App Service regardless how many of them there are
Additional details:
this ASP.Net Core 3.1 project
we use "Azure App Service deploy" task
You will probably want to use deployment groups by changing your agent to a deployment group agent phase.
The deployment group allows you define multiple target environments, add tags, and target those tags on specific phases. I'm suspecting that you have installed the agent on all the target machines, but it will only run once and will pick from any agent registered in the pool. Instead, I believe you want it to run on every target.
You can even configure the release pipeline to automatically deploy the last deployment release as new targets are added.
You might reference this answer about the difference between an agent pool and deployment pool: Azure Devops (VSTS) Different between Agent Pool and Deployment pool
I have a local VM that has successfully been running builds from VSTS.
After the builds are completed I have a deployment job that pushes my artifacts to a number of servers. This has been working fine for the past few months.
This morning, I received a message that I was out of "deployment minutes" and my deployments failed, however my builds completed.
Obviously it was building locally, but deploying in the cloud.
Is there a way I can configure my agent or my deployment job within VSTS to use my local agent?
You should just be able to switch your release definition to use the same agent queue as your builds. In each environment, click on each phase and change the agent queue it uses from "Hosted" to whatever you named your local agent queue.
You may need to install additional software (Azure PowerShell, if you're deploying to Azure, for example), but it will work the same -- the build and release agents are exactly the same software and use exactly the same tasks.
You should be able to add your agent to the pool (it requires some software installed there of course) and then select it instead of a hosted environment in the deployment step configuration:
Agent pools
At the bottom you can find:
The hosted pool provides all VSTS accounts with a single hosted build agent and a limited number of free build minutes each month. If you need more hosted build resources, or need to run more than one build concurrently, then you can either:
- Deploy your own on-premises build agents
- Buy additional hosted pipelines
Here is where I finally found the option to specify which agent the release should run on:
VSTS Build Agents VS Agents installed directly on the server (Deployment Groups). Which is more secure? What do you guys use?
When it comes to deploying your code, VSTS gives you two options (1) Install a agent on a build server and deploy that way or (2) install an agent directly on the actual servers themselves (this is called Deployment Group - mainly because you can install agents on several servers and group them).
If you use option (1) your code is deployed from the build agent to your prod server using WinRM usually.
If you use option (2) the code is downloaded directly to the prod server you want to deploy to and the agent on that box deploys the code.
I have some reservations about installing agents directly on my production boxes and connecting them to VSTS (option 2).
Which method do you guys use?
Whether use option1 or option2 for deployment it’s depend on whether you want to deploy parallel on the agent machines or not.
If you only need the tasks deployed by a given agent, you can deploy with option1.
If you want the tasks deployed by multiple agents, you can use option2.
For a deployment group, you can add multiple machines. So in your release definition, if you run tasks on a deployment group, you can deply all targets in parallel.
A deployment group is a logical set of deployment target machines that
have agents installed on each one. Deployment groups represent the
physical environments; for example, "Dev", "Test", "UAT", and
"Production". In effect, a deployment group is just another grouping
of agents, much like an agent pool.
When authoring a VSTS or TFS
Release definition, you can specify the deployment targets for a phase
using a deployment group. This makes it easy to define parallel
execution of deployment tasks.
More details about deployment groups, you can refer deployment groups.
For security of the two options, both of them are safe enough. But you can assign security roles for deployemnt groups.