Skip to content

Deployment versions

It is possible to maintain multiple versions of a deployment. All versions in a deployment share the same in- and output fields such that they can be used interchangeably, but the deployed code package, programming language, memory allocation and other settings can differ.

Each version of a deployment is always available (if the building succeeds), meaning that you can make requests to any version of a deployment at any point in time.

Creating a new version of an existing deployment

When using the WebApp, a first version is automatically created while creating the deployment. You are able to add more deployment versions at a later time using UbiOps' deployment versioning system.

In the left navigation bar, click on Deployments. Select the deployment to which you want to add a new version.

Then, click on the Create version button in the versions pane at the top left. The version creation form will appear.

Fill in the version name and the programming language. Please note that the programming language cannot be changed after creating the version. Click on the Upload code button to upload the ZIP file for the new version. The required structure of the ZIP file can be found under Deployment package structure.

At the Deployment mode section you can specify the deployment mode of your version. This can either be batch or express. For more information see the Deployment modes section

Other configuration parameters are optional, such as for example the memory allocation. These can be set in the Advanced parameters. As with deployments, you can assign labels to versions to easily filter them later on.

Finally, click on the Create button to create the new version.

Default versions

The more versions a deployment has, the harder it is to track which version is the 'latest' or 'correct' version to make a request to or to be used in a pipeline. When this happens, it is possible to mark a version of a deployment as the default version of that deployment, which allows to do the following:

  • Specifying a version when making a request to a deployment is not necessary. If not specified, the request will always go to the default version that is currently set.
  • If an object in a pipeline refers to the default version of a deployment, the request will go to the default version that is currently set.

There can only be one default version per deployment at a time. If the default version is changed, it is effective immediately, meaning that any request after this moment will be directed to the new version. Note that already created but unprocessed batch requests will still be processed by the version that was the default when creating the batch request. Click on Edit in the Deployment details page in the WebApp to change the default version of that deployment.

Only versions that have passed the building stage and are available can be marked default. The first version of a deployment is always marked default.

To make a request to the default version, navigate to the Deployment details page in the WebApp and click on Create Request.

See Monitoring for information on how to monitor your deployment.

Referencing a default deployment version

The default version of a deployment can be used in a direct and batch request and when creating a request schedule.

Revisions and Building

UbiOps maintains a full history of the ZIP packages uploaded to a version, which allows for tracing back the code that was deployed at any point in time. In the WebApp, navigate to Revisions to see the history of packages.

Each uploaded package triggers a building process, which prepares the deployment code for requests. For more information, click on the expansion button to see the builds of a revision, along with the status and a description of what triggered the build.

During building, the required packages for the deployment are installed, an instance that will handle the requests is deployed and the deployment is initialised. If the building completes successfully, the version will be in available state, which means it is ready to accept requests immediately.

However, if the building fails at any of these steps, the version will be unavailable. The building might fail because of errors in the deployment file or during initialisation of the deployment class. If this happens, view the logs of the version to see more details on what went wrong. No requests can be made to an unavailable version.

Deployment modes

Every deployment version needs to have a deployment mode, which can either be express, or batch. Express deployments work with direct requests, which are synchronous and have a maximum duration of 1 hour. Most deployments will fall into this category. Batch deployments work with batch requests, which are asynchronous and have a maximum duration of 48 hours. Since they are asynchronous you need two API calls for your requests, one to create the request, and one to fetch the results once it is done processing. Deployments for model training or optimization algorithms tend to fall in the batch category, as they take much longer to process.