In Azure DevOps, "self-hosted agents" refer to agent machines that you set up and manage yourself, instead of using Microsoft-hosted agents. These self-hosted agents can be beneficial in various scenarios:
Security and Compliance: In some organizations, data security and compliance policies may require running build and deployment processes on infrastructure managed within their own network.
Access to Internal Resources: Your build and deployment processes may require access to internal resources (databases, network drives, etc.) that are not accessible from external Microsoft-hosted agents.
Performance and Customization: Self-hosted agents can be tailored to specific hardware configurations, which might be necessary for resource-intensive builds or specialized build environments.
Cost Management: Azure DevOps provides a certain number of free Microsoft-hosted parallel jobs, but if you have large-scale or resource-intensive projects, self-hosted agents can be more cost-effective in the long run.
Reducing Build Queue Times: When using Microsoft-hosted agents, you share resources with other users, which might result in longer build queue times. Self-hosted agents allow you to control the resources dedicated to your builds, potentially reducing waiting times.
Offline Environments: If you have environments without continuous internet access, self-hosted agents can be used to facilitate builds and deployments within those isolated networks.
In this post i will be:
- Generating a Managed VM Image using Packer.
- Saving the Managed image to a Image gallery within my tenant.
- Create a Virtual Machine Scale Set(VMSS) from the said image.
- Register the VMSS as DevOps Self-Hosted agents.
- Run a time intensive project using self-hosted pool to see how VMSS will autoscale.
- Then update the VM image with new build and see how we can update the existing Self-hosted agents.
