Deployment basics

Deployment involves grouping the Azure Sphere devices that should run the same applications and OS versions, packaging the applications you want to run on each group of devices, uploading the packages to the Azure Sphere Security Service, and assigning the deployment to a group of devices. This topic defines the fundamental elements involved in deployment.

Device IDs

An Azure Sphere device ID uniquely identifies an individual Azure Sphere chip. The device ID is stored on the device itself. All the other elements of a deployment are stored with the Azure Sphere Security Service.

Products

A product identifies an Azure Sphere MCU that is incorporated into a connected device to perform a specific function. As the manufacturer, you create a product for each model of connected device, such as a dishwasher or coffeemaker. For example, Contoso creates a product for its DW100 dishwashers and assigns this product to each DW100 dishwasher during manufacturing. Each product has a GUID that is unique within the tenant and cannot be changed.

Every connected device has a single product, but a single product can be associated with many devices. Each product has a name that must be unique within its tenant, along with a description. The product name and description provide a human-readable way to distinguish one product from another. The name and description of the product can be modified as often as you wish.

Device groups

A device group is a named collection of devices of the same product type. Device groups provide a way to scale application deployment to many devices. Each device belongs to exactly one device group. When you create a product, default device groups are created within the product to assist with basic functionality such as testing and production deployment. These are the default device groups:

  • Development: The Development group is intended for use by developers who sideload applications as part of the development process. By default, devices in this group receive the Retail Evaluation OS feed; application updates are disabled. To test against a different OS version, you can change the default OS for the group.
  • Field Test: The Field Test group is intended for use by developers who are testing devices in a lab or field trial. By default, devices in this group receive the Retail OS feed and all application updates.
  • Production: The Production group is intended for production devices. By default, devices in this group receive the Retail OS feed and all application updates. This group is intended for production devices of that product.
  • Field Test OS Evaluation: The Field Test OS Evaluation group is intended for use by developers who are verifying the compatibility of new versions of the Azure Sphere OS with applications on test devices in a lab or field trial. By default, devices in this group receive the Retail Evaluation OS feed and all application updates.
  • Production OS Evaluation: The Production OS Evaluation group is intended for use in verifying the compatibility of new versions of the Azure Sphere OS with production applications. By default, devices in this group receive the Retail Evaluation OS feed and all application updates.

You may choose to create additional device groups to organize your products. For example, Contoso might use the Development group for the devices in its engineering lab and the Field Test group for the devices that its deployment team uses in the corporate operations center. Instead of placing all production devices in the Production group, however, Contoso might create groups for devices in various geographic regions, so that it can easily deploy localized versions of its applications. The grouping criteria are left completely to your discretion.

To deploy applications to Azure Sphere you assign those applications to device groups. Each device within a device group will automatically receive the assigned applications.

Applications

An application is a program that performs tasks specific to certain connected devices. A deployment delivers the application to the products that are associated with those connected devices.

Images and image packages

An image is a binary file that represents a single version of an application or board configuration. Images are immutable: you cannot modify an image after it has been uploaded. For an application, the image includes the binaries for the application along with its image metadata. An image package is the combination of an image with its metadata that is produced by the build process. Every time the SDK builds or rebuilds an Azure Sphere image package, it uses a new unique image ID.

When Contoso develops an application for its DW100 dishwashers, the SDK creates an image package that can be deployed to any device groups.

Chip SKUs and system software

As a product manufacturer, you develop and manage applications, whereas Microsoft develops and manages system software components. System software components target chip SKUs. The chip SKU (stock keeping unit) identifies a particular type of Azure Sphere-compatible MCU. The chip SKU is assigned by Microsoft and cannot be changed. Microsoft uses this SKU to deliver the correct system software updates to each Azure Sphere device.

Deployment

In the simplest terms, a deployment is the delivery of a set of image packages to one or more devices. You create a deployment by:

  • Creating a product by using azsphere product create
  • Creating additional device groups, if necessary, by using azsphere device-group create
  • Assigning devices to device groups by using azsphere device update
  • Creating image packages by using the Azure Sphere SDK
  • Associating the image packages with a device group by using azsphere device-group deployment create or azsphere device-group deployment update

Create a deployment provides step-by-step instructions for creating cloud deployments.