The PackageManager API submits requests to the deployment engine for processing. Each request represents an instruction for the deployment system to carry out a defined set of actions, collectively referred to as a deployment operation.

The operation associated with a request depends primarily on the API used to initiate it and, in some cases, its parameters. Internally, the deployment pipeline models its work as a series of deployment operations derived from an API called and its arguments.

For example, PackageManager.MovePackageToVolumeAsync() submits a request to perform a Move Package operation. In most cases, method names serve as a clear indicator of the deployment operation being requested.

Some operations may be requested through multiple APIs. For instance:

• PackageManager.StagePackageAsync()
• PackageManager.StagePackageByUriAsync()

have different method names and parameter sets, yet both result in a deployment request to perform a Stage Package operation.

Deployment Operation

Deployment supports dozens of operations, including:

• Add Package
• Stage Package
• Register Package
• Remove Package
• Provision Package
• Deprovision Package
• Move Package
• Repair Package
• Reset Package
• Add Volume
• Remove Volume
• …more…

You’ll see references to deployment operations throughout deployment logs and telemetry.

The list of supported operations has grown steadily over time, as new servicing and management behaviors have been introduced. Most notably, this occurs when new operations and scenarios don’t naturally align with existing operations.

Deployment Request and Queue

A deployment request consists of a deployment operation, the input parameters provided with the requested operation, the caller’s user context, security context and other operational properties.

Deployment requests are added to an in-memory priority queue (aka the deployment queue) in the deployment engine. Because deployment is multithreaded, multiple requests can be dequeued and processed in parallel, subject to concurrency controls where required.

For example, if a Repair Package operation is in progress for Contoso.Parts_1.2.3.4_x64__1234567890abc, a Move Package request for the same package can be submitted. The Move request will be enqueued, but it won’t be dequeued for execution until the Repair operation completes.

Concurrency

Concurrency constraints may apply to an entire deployment request (as in the Repair/Move example) or to specific portions of the work required to process the request. For instance, as previously mentioned an Add Package operation can involve staging the package’s payload. Deployment supports a limited number (N) of concurrent staging activities (such as downloading package content from a network source). The value of N depends on system configuration, hardware capacity, current system activity and other factors.

If N staging operations are already in progress, additional requests are accepted and processed, but any work requiring staging will be throttled until one of the active operations completes its staging work.