Releases are how you update your application components in your customer’s installs. This doc covers how releases work, how to create them, and how to monitor them.

​
How Release Work

​
Deploys

In order to run an app component in an install, you must create a deploy. A deploy does two things:

  1. Sync a component build artifact to an install’s local registry.
  2. Provision that component in the install’s sandbox.

Creating a single deploy is pretty straightforward. But, when you have a lot of installs, managing deploys for all of them can quickly become a challenge. This is where releases come in.

​
Managing Deploys at Scale

A release will create and monitor multiple deploys for you. You can configure what installs to deploy to, how many deploys to create at a time, and how long to wait before creating them. Once created, a release will also monitor the deploys, so you can see if any of them fail.

​
Creating a Release

The simplest release you can create will immediately deploy the latest build of a component to all installs simultaneously.

nuon releases create -c {component_id} --latest-build

In practice, though, you will probably want to configure some options.

​
Build Options

Instead of using the latest build, you can specify a build by ID.

nuon releases create -c {component id} -b {build id}

You can also tell Nuon to create a new build. See the Create Builds guide for more info.

nuon releases create -c {component id} --auto-build

​
Install Options

By default, a release will immediately deploy to all installs simultaneously. You can optionally configure a delay, as well as limit the number of deploys created at a time.

For example: if you wanted to deploy to one install at a time, and wait an hour between each deploy, you would execute the following.

nuon releases create -c {component_id} --latest-build --delay 1h --installs-per-step 1

​
Monitoring Releases

​
Monitor the Release

Once a release has been created, you can use the CLI to see its status.

nuon releases get -r {release_id}

You can also see the status of each step and the deploys within them.

nuon releases steps -r {release id}

​
Monitor Deploys

You can also see the status of each deploy. Since deploys are children of installs, you will use the installs sub-command instead of releases.

nuon installs get-deploy -i {install_id} -d {deploy_id}

​
Debug Deploys

If a deploy fails, you can look at the logs to see why.

nuon installs deploy-logs -i {install_id} -d {deploy_id}

Deploy log retention is 24 hours, but you can still see metadata about the logs by passing in the --json flag.

If the issue is not apparent from the logs, or there are no logs, look at the deploy plan for more information. A plan is created for each deploy, and it contains all the information used to execute the deploy job.

The deploy plan is a JSON object, so we recommend using JQ to format it for readability.

nuon installs print-deploy-plan -i {install_id} -d {deploy_id} | jq

Deploy plans can be quite large and complex, so the CLI has some options you can use to focus on the specific parts of the plan you should check first.

The job config will show you how the deploy job was configured.

nuon installs print-deploy-plan -i {install_id} -d {deploy_id} --print-job-config

The intermediate data contains all the data used to render the variables from the component config. You can use this to verify that all the data you need for your components is available.

nuon installs print-deploy-plan -i {install_id} -d {deploy_id} --intermediate-only | jq

The rendered variables contain the values of the variables after they were rendered using the intermediate data. You can use this to verify that variables in the component config are being interpolated with the correct values.

nuon installs print-deploy-plan -i {install_id} -d {deploy_id} --rendered-vars
MigrationsUsing Variables