Deployment Actions

Qovery allows you to manage the deployment lifecycle of your services and environments via a set of Deployment actions (example: deploy, redeploy, restart, stop etc..). These actions can be triggered via the Qovery web console, via the Qovery API, via the Qovery CLI or from your CI/CD depending on your integration type.

You can imagine the deployment lifecycle of a service or environment like a state machine:

• each state is identified by a Deployment Status
• the execution of a deployment action will modify the state of the service/environment until it reaches a final status (ok or error)
• the list of allowed Deployment action depends on the current Deployment Status. Example: if the deployment status is Deployment Ok, you can trigger only the action Stop. This will stop the execution of the service (deployment status Stopped).

Example: When a new application is created within Qovery, the application will have the deployment status Ready. Once the action Deploy is executed on the service, the service will go through the statuses Queued, Building, Deploying and then finally on the status Deployed (meaning that the application is correctly deployed). At this point, you can trigger only the action Stop (This will stop the execution of the service, moving the application to the deployment status Stopped).

You can find the status of the last deployment directly in the Qovery console in the service or environment list:

Note that the deployment status of the environment is built based on the deployment statuses of each service within it.

Deployment Status and Running Status do not provide the same information. Just because a deployment has failed does not mean your application is not running anymore. Monitoring both your deployment and service statuses allows you to know exactly which applications are currently running on your platform. Have a look at this section for more information

You can decide to execute a deployment action on: 1. an environment: via the Play button at environment level, the action will be executed on each service within the environment. To know more about the deployment order of your services, have a look at the Deployment Pipeline 2. a single service: via the Play button at service level, the action will be executed only on the selected service. 3. a subset of services: selecting one or more services from the service list and using the floating action button.

Note that all the deployment actions are available via any interface described within this section.

You cannot queue deployment actions on one environment. Example: you can't trigger the deployment of service A and stop service B at the same time. You need to wait for the deployment of service A to finish before triggering the pause of the service B

Deployment Actions

You can find below a description of each deployment action, including its purpose and the deployment status your environment and/or service will go through.

Deploy

The Deploy action allows you to create the resource necessary to run your code on your Kubernetes cluster. This action is available only if the service or environment have never been deployed.

Based on the configuration of your services within, a certain number of Pods will be created in a dedicated Namespace of the target Kubernetes cluster.

The commit id or tag that will be deployed is the one visible on the interface and not necessarily the latest version (unless the auto-deploy feature is activated)

Once triggered, the deployment of a service goes through the following deployment statuses:

• QUEUED : the deployment has been queued and it is waiting for the necessary resources to be allocated to manage your request
• BUILDING : the Qovery engine is downloading the git repository and building your code. At the end of this step an image is built and pushed to a registry available on your cloud account. The status will become BUILD ERROR in case of issues on building your code
• DEPLOYING : the pods are being created on your cluster based on the image built on the previous step. The status will become DEPLOYMENT ERROR in case of issues on deploying your service. A service is considered un-healthy if the Kubernetes readiness probe check is never OK (more info on readiness probe).
• DEPLOYMENT OK : all the requested pods have been created and the service is correctly running (liveness and readiness probes are ok).

If the deployment was triggered on the entire environment, the environment will go through the following deployment statuses:

• QUEUED : at least one service is in status QUEUED
• BUILDING : at least one service is in status BUILDING
• DEPLOYING : at least one service is in status DEPLOYING
• DEPLOYMENT OK : at least one service is in status DEPLOYMENT OK but none of them is in error (BUILD ERROR or DEPLOYMENT ERROR)
• DEPLOYMENT ERROR : at least one service is in status DEPLOYMENT ERROR

Redeploy

The Redeploy action allows you to update the remote configuration of your services based on their configuration on Qovery side. If any difference exists (vCPU, number of instances, code version etc..), a new set of pod will be created with the new configuration and replace the existing ones. If there are no configuration differences, nothing will happen on the pods running on your cluster (not even a restart, please use the Restart Service feature). This action is available only if the Deploy action has been triggered at least once on the service or environment.

When replacing the pods of your application, Qovery uses the rolling-restart deployment logic:

1) Deploy new version of instance #1.

2) New version of instance #1 is running => kill previous version of instance #1.

3) Deploy new version of instance #2.

4) New version of instance #2 is running => kill previous version of instance #2.

And so on...

You can trigger the re-deployment of a service or of the entire environment. The service or environment goes through the same deployment statuses described in the deployment section.

A redeploy on an environment triggers the deployment of any service in the environment, no matter their previous status (even stopped ones)

Stop

The Stop action allows you to stop the execution on the cluster of the selected service or environment (deployment status = Stopped). This action is available only if the current deployment status is Deployment OK or Deployment Error.

The effect on your cluster of the stop operation is different depending on the type of service:

• Application, Container, Container DB : Pods of those services are stopped. Any attached storage is preserved
• Cloud provider Managed DB: the database is paused (only for AWS, not working on Redis)

Restart Service

The Restart Service action allows you to restart the pods of your service without applying any configuration change. This action is available only if the current deployment status is Deployment OK and only for a single service.

Once triggered, the deployment status service goes through the following statuses:

• RESTARTING : the request to restart has been received
• RESTARTED : all the pods of the service have been restarted
• RESTART ERROR : Qovery couldn't process the restart request

Cancel Deployment

The Cancel Deployment action allows you to abort any Deploy or Redeploy action and stop the execution of the deployment pipeline. This action is available only if the current deployment status is Queued or Building or Deploying.

If a deployment of a service A is already ongoing, the cancel operation will stop the deployment execution and rollback the service A to the previous version. Any service already deployed during the pipeline execution will not rollback to the previous version.

For Lifecycle Jobs, the cancel operation is not taken into account unless it is forced via the checkbox available in the "Deployment cancel" modal.

Deploy other version

The Deploy other version action allows you to deploy a different version for your service. This action is available no matter the deployment status of the service.

Once you click on the action, this panel will appear, and you will be able to choose the version you wish to update/rollback (either git commit or image Tag).

By pressing on the Deploy button, a deployment of the service will be triggered using the selected version.

Deploy latest version

The Deploy latest version action allows you to deploy the latest version for any of your services within the environment. This action is available no matter the deployment status of the service and only at environment level

Once you click on the action, this panel will appear, and you will be able to choose the services you wish to update to the latest version (only for services with source = git repository).

By pressing on the Deploy button, a deployment of the service will be triggered using the selected version.