Lesson 10.01: Agent Jobs

Agent jobs require an installed Azure DevOps agent to execute the job. Agent machines can be hosted agent machines or on-premise machines depending on the targets of deployment, which we discuss in this lesson.

Depending on the execution, steps technology requirements of the agent defer. The requirements of an agent can be demanded as demands of an agent phase. For example, if your deployment steps involve Azure CLI, to deploy to Azure target, your agent machine needs to have the Azure CLI available. Demands in the agent phase are used for these types of technology demands. See Figure 10-1.

If you are deploying to a cloud target such as Azure or AWS, you can use Microsoft hosted agents to execute deployment actions. However, if you are deploying to an on-premise target or a more secure Azure target such as Azure App Service Environment, you might need to set up your own deployment agent machine. Most of the time the on-premise environment would be behind a corporate firewall, and the hosted agents will not have a line of sight to execute deployments against such targets. Similar to that, in an Azure App Service Environment (ASE), access to even platform services would be allowed only within the defined virtual network in Azure ASE. Hence, you need to set up a virtual machine configured as an Azure DevOps agent, inside the Azure ASE virtual network, which can access the platform services in an Azure ASE.

There are parallelism options similar to build pipelines that allow you to run the job steps in a single agent, or multiple configurations as specified in multipliers. When running on multiple configurations, you can specify the number of agents limit. You can run the same set of tasks in multiple agents as well with a multi-agent option. See Figure 10-2. These options would be useful if you want to deploy to different targets based on if a configuration specified may be to enable deployment on the debug configuration to diagnose some issues while having a release configuration target as well.

You can selectively set to download or skip downloading artifacts in an agent step. See Figure 10-3. For example, if you have a separate agent job to run test automations, you may not need to download artifacts other than automated test scripts that need to be executed. Hence, you can skip the deployment files and only download the artifact related to the test execution.

You can set the Allow scripts to access the OAuth token in an agent phase so that any script task in an agent job can use the system access token to access a REST API of Azure DevOps.

There are two timeout settings available for agent jobs. A timeout defines how much time a job can be executed in the agent. A job cancellation timeout defines how much time a job is given to complete when a cancellation request is made before the server terminates the job.

The execution options allow you to define the conditions of how the job may get started. See Figure 10-4. You may want to set up a rollback procedure in case the deployment fails, which is defined in the previous agent job. In that scenario, you can set it to execute on a previous job failure in the current agent job and define the tasks for rollback. In a situation where you want to execute automation tests after a successful deployment job, you may set up one agent job to do the deployment upon successful execution of that job to execute the functional tests on the subsequent job with the condition that the previous job is successful. However, unlike the build agent jobs, the execution happens in release agent jobs in the defined sequence, and there is no option to define dependencies as in build agent jobs, which are not required as execution happens in the sequence the jobs are set up in the release pipeline.

You can use many tasks available by default in Azure DevOps as well as tasks getting added with the marketplace extensions in Agent jobs to execute the required deployment steps. These deployment steps may involve setting up infrastructure of a given environment target, deploy your applications, and even executing functional and integration tests. In the marketplace for Azure DevOps, you can find tasks supporting various platforms and almost all actions you are required to do. If a task cannot be found, you can implement them on your own, which we will discuss in more detail in Chapter 11. You can group your tasks as task groups to reuse them in multiple agent jobs, and we talked about task groups in Chapter 2.

In this lesson, we discussed using agent jobs in release pipelines.

Lesson 10.02: Deployment Group Jobs

Deployment group jobs are meant to execute on defined deployment groups. We have talked about deployment groups and deployment pools and how they can be added with target machines with roles in Chapter 2 of this book.

In release pipelines, you can use deployment groups defined in team projects in the deployment group jobs. You can use the roles defined in deployment group targets as required tags for a given deployment group phase. For example, any machines with a role set to WebSvr can be identified as Web Servers using the tags in the deployment group job, which need to be deployed with web server deployment steps of your application. See Figure 10-5.

Similar to an agent job, the deployment group job also has a timeout and job cancellation timeout settings that you can use to determine how much time a job can be executed before timing out and how much time is allowed to complete the job once a cancellation request is made before terminating, respectively.

Targets to deploy in parallel settings define how many targets the deployment actions execute in parallel when more than one target in the deployment group is available based on the selected tags and defined roles in the targets of the deployment group. This enables you to deploy to your load balanced multiple web servers, etc., in parallel. Timeout 0 means infinite time out and the timeout is defined in minutes. See Figure 10-6.

Similar to agent jobs in the deployment groups, you can also define which of the artifacts are to be downloaded in a given job. OAuth token access and execution of jobs based on conditions can be also set similarly to agent jobs. These features can be used to define rollback and test execution scenarios with deployment groups as we have explained with agent jobs in the previous lesson. When using test executions, the role in such a machine can be a test client role based on a tag such as TestClient.

The tasks can be used in deployment group phases similar to agent jobs to achieve deployments based on their target roles. Even in the marketplace tasks, task groups can be utilized as required.

In this lesson, we explored the options available in the deployment group jobs to set up release pipelines in Azure DevOps.

Lesson 10.03: Agentless Jobs

Agentless jobs are useful to execute steps that do not require a machine to perform the steps that are being executed. There are a limited number of steps that can be executed on an agentless job. See Figure 10-7.

You can use delay steps to wait for a given time after a given agent or deployment group job, using an agentless phase. Once the delay time is passed, the next agent or deployment group job can be executed. This type of delay would be useful in scenarios such as when you are provisioning infrastructure on cloud platform targets. There might be time requirements once infrastructure commands are executed on such cloud platforms to provision the required platform resources. Therefore, the delay task could be used to wait on such a required time.

Similar to gates applied between stages of a pipeline, in pre- and post-deploy stages, you can utilize the agentless phase to implement such gating between agent or deployment group jobs or by using tasks such as Invoke Azure Function, Invoke REST API, Query Azure Monitor Alerts, and Query Work Item tasks. For more information about gating, refer to Chapter 9.

The manual intervention task can be used to implement an approval, a rejection step in between the agent, or the deployment group jobs. These approvals can be useful in scenarios such as where you want to manually perform an action before executing the next steps of the pipeline.

In agentless jobs, there are minimal sets of settings compared to the agent or deployment group jobs. See Figure 10-8. The agentless job can be executed for multiple configurations as specified in multipliers. A timeout can be specified to execute the agentless phase. The run conditions allow you to define if the agentless phase should be executed based on previous step success or failure; or using a custom condition, which help you to determine whether you need to execute an agentless job based on the pipeline execution flow.

In this lesson, we discussed the agentless phase and usage of the agentless steps in release pipelines.

Lesson 10.04: Variables

Release pipelines similar to build pipelines contain the variables. In the variables tab of release pipelines, you can define the key and value pairs. The sensitive information contained in variables can be defined as secrets, and such variable values are not visible once marked as sensitive. See Figure 10-9.

The variables in a release pipeline can be scoped to the release or to a stage as shown in Figure 10-9. The same variable can contain a different value for each stage. For each variable in the release pipeline, you can set it to settable at release time, which allows the values of those variables to be set at the time of the release creation. See Figure 10-10.

Variable groups, as explained in Chapter 2, can be used to keep shared variables for multiple release pipelines, or even to share variables with the build pipelines. Such variable groups can be utilized in release pipelines with the scope of release or with a stage(s) scope. See Figure 10-11.

Variables can be reused using a $(variablename) in another variable as it automatically resolves. This is useful to repeating values in multiple variables and makes sure variables are containing unique values, and changing one place is only required to change variable values.

In this lesson, we discussed variables and their usage in release pipelines.

Lesson 10.05: Other Useful Features

Release pipelines have a couple of other useful features: in the retentions tab, options tab, history, tab and in a release menu such as import, export options.

In the retentions tab, you can set release retention settings. There is a link to set up project defaults as well for retentions. You can set the number of days to retain a release and the minimum number of releases that should be retained regardless of the retain dates setting. Days to retain specifies the number of days a release would be kept. Regardless of the number of days, the number of releases specified in the minimum number of releases to keep will be preserved. See Figure 10-12.

You can set the release number format and add a description to the release definition. The release number can be used with a build number with a revision to give more meaning to the full release number as an example. See Figure 10-13.

The options tab has integration options for the release pipeline to integrate with the repositories, boards, and external service Jira as well. See Figure 10-14.

The history of the release pipeline provides information about revisions in the release pipeline where you can make comparisons of versions as well as revert to a given version if required.

In this lesson, we discussed a few of the useful options available with release pipelines.

Summary

In this chapter, we explored agent jobs, deployment group jobs, and agentless jobs and their usage in detail. Additionally, we looked at a few other features such as variables, options, integrations, retention settings, and histories of release pipelines and their usage.

In the next chapter, we explore the REST API and the command-line interface features and the usage of them.