Deployments

Overview

A deployment makes an application's release available in a scope so it can run and be used. The deployment process delivers an asset to the underlying technology that will be running the application (e.g., virtual machines, Kubernetes clusters, serverless, or other custom technology) along with parameters that have been configured for that environment.

Key notes about deployments:

• The unit of deployment is an asset: Each deployment is tied to a specific asset that is included in one of your application's builds, which must have been previously released (with a semantic version).
• Progressive Blue-Green strategy: Deployments on servers, Kubernetes, and serverless support phased rollouts with request-level traffic switching, allowing you to gradually send traffic to your new deployment.
• Deployments can be rolled back: Every deployment has a fast rollback option to revert its effects before they become permanent.
• Approval and policies: Deployments support approval and policies to implement fine-grained business logic and ensure compliance.
• Deploy multiple environments at once: You can go beyond deploying a single environment by grouping multiple deployments together in a group.

The rest of this guide will explain how deployments work in detail, so you can better control them and integrate your own processes with nullplatform.

Lifecycle and strategies

When you create a deployment, it goes through several stages outlined in this table:

Status	Description
CREATING_APPROVAL	Waiting for approval before the deployment can be created.
CREATING_APPROVAL_DENIED	The request to create the deployment was denied.
CREATING	The deployment is being created.
WAITING_FOR_INSTANCES	The deployment is initializing instances.
RUNNING	The deployment is up and running.
FINALIZING	The deployment is wrapping up final steps.
FINALIZED	The deployment is complete and stable.
CANCELLING	The deployment is being canceled.
CANCELLED	The deployment was successfully canceled.
FAILED	Something went wrong, and the deployment failed.
ROLLING_BACK	The deployment is being rolled back to a previous stable version.
ROLLED_BACK	The rollback is complete.
DELETING	The deployment is being deleted.
DELETED	The deployment was successfully deleted.

There are essentially two deployment strategies:

• Initial deployment: Used for first-time deployments when there's no previous deployment on the scope.
• Blue-Green deployment: Used to create a new deployment that will replace an already-running deployment. This strategy involves creating a new runtime (the "green" environment), allowing gradual traffic switching and rollbacks to the previous runtime (the "blue" environment).

Review this diagram to understand how the two deployment strategies work.

Strategy data

When working with the API, you can access the strategy_data field which tracks deployment's progress using these fields:

Field	Type	Description
switched_traffic	integer	Current percentage of traffic on new version (0-100)
desired_switched_traffic	integer	Target traffic percentage for new version
amount_instances_to_wait	integer	Required number of instances before proceeding
healthy_instances	integer	Current count of healthy instances
launched_instances	integer	Total instances launched
switch_traffic_step	boolean	Indicates active traffic switching phase

Deployment group

Whenever you deploy multiple scopes at once, you're creating a deployment group. Deployment groups give you the ability to centrally control multiple individual deployments (which are still created and can be managed in a traditional single-deploy fashion).

Key notes about deployment groups:

• Flexible scope grouping: You can create deployment groups that include scopes of different type and dimensions.
• You can still operate individual deployments: Since individual deployments still exist, you can cancel or roll them back (affecting the group's overall status).
• Finalized status: A deployment group is only marked as FINALIZED when all its individual deployments are successfully finalized.
• Canceling a group: You can only cancel a deployment group if every individual scope is already in the RUNNING status (past the CREATING stage).
• Rolling back a group: You can roll back a deployment group at any time, unless the group is in the FINALIZING status.

Approvals and policies

To add an extra layer of control, you can set up approval processes for when a user creates a deployment. This lets you decide which actions (like deploying to production) will require approval, manual review, or be automatically denied.

You can create policies to align approval processes with your business needs. For example, you might block deployments during a holiday freeze unless the user has a certain expertise or job title.

Note that if an approval action is required for creating a deployment and the request is denied, the deployment status will be set to CREATING_APPROVAL_DENIED.

For more details, check out our approvals section.

Deleting a deployment

There's a special situation where an active deployment is not replaced by a new one—this occurs when a scope is stopped. In this case, the deployment status will be set to DELETED. Note that this is only possible on server instances and Kubernetes scopes.