Deployment Pipeline

Before you begin, this documentation assumes the following:

You have created an Environment and one Service (application, db or job)

When the deployment of an environment is triggered, Qovery executes what we call Deployment Pipeline. It basically defines the operations shall be performed to properly deploy every service defined within your environment (build the code of service X, push the image on a registry, deploy service X on the Kubernetes cluster etc..)

A pipeline is composed of an ordered list of Deployment Stages. Each Stage has an execution order assigned within the pipeline: If a stage A has an execution order lower than stage B then B can be executed only if the execution of stage A is completed.

Each service of your environment belongs to one (and only one) Deployment Stage. This allows you to define at which moment of the deployment pipeline a service should be deployed and thus respect any service inter-dependency (e.g. your front-end needs to be started after the back-end, your db needs to be started before your back-end etc..).

Below you can find a visual example of how the pipeline looks like:

Deployment of a stage

When the deployment pipeline execute the deployment of a stage, the services within it will go through the Build and Deployment phases.

Application building

Important note: If you already have an image available on a container registry that has been previously created by your own CI/CD, it might be interesting for you to reuse it instead of re-building it again on Qovery side. Have a look at this section on how to deploy it.

The Building process is managed by the Qovery CI which downloads your repository and generates the final image that will be run on your Kubernetes cluster.

The build operation of each service within a deployment stage is executed in parallel with a parallism of 7.

Once the operation is completed, the built image is pushed in the mirroring registry for deployment (check here for more information).

Check this section to know more on how to reduce the build time of your application.

By default, the nodes building your application have the following resources: 4CPU and 4 GB memory. If you need more resources, get in touch with our support.

Application deployment

The deployment process is managed by the Qovery engine via helm charts. The engine generates a custom chart to deploy your application/job, unless you have already provided your own helm chart.

The deployed image is pulled from the mirroring registry (check here for more information)

The deployment operation of each service within a deployment stage is executed in parallel with a parallism of 7.

Example If you have 10 applications to be deployed within a stage, Qovery will:

• build 7 applications in parallel. Once the build of one application is terminated, Qovery will start immediately another one until all the applications are built.
• deploy 7 applications in parallel on your Kubernetes cluster. Once the deployment of one application is terminated, Qovery will start immediately another one until all the applications are deployed.

The parallel build and deployment is a feature in beta and free for everyone during the beta phase

Default Pipeline Setup

By default, the deployment pipeline is constituted of 4 deployment stages with a default service assignment rule:

• "0.DEFAULT DATABASE": any new service of type DATABASE will be added to this stage.
• "1.DEFAULT JOB": any new service of type JOB will be added to this stage.
• "2.DEFAULT CONTAINER": any new service of type CONTAINER will be added to this stage (application deployed from a container image).
• "3.DEFAULT APPLICATION": any new service of type APPLICATION will be added to this stage (application deployed from a git repository).

Once the service is created, the assigned stage can be modified afterwards. See this section for more information.

This default assignment is maintained as long as you do not delete or rename the default stage. If the default stage is modified or deleted, the service will be automatically added to the latest stage (based on the stage deployment)

Visualizing and Modifying the Pipeline

You can access and modify the pipeline configuration from the environment settings. Have a look at this section to know more.

Best practices to speed up build time

Here you can find some best practices you can follow to ensure you benefit from all the caching system and reduce the build time.

Review your Dockerfile structure

Review the content of your Dockerfile to find performance improvements. There's a list of suggestion on the Docker website, feel free to ask for help on our forum

Benefit from the build and deployment parallelism

Try to put on the same deployment stage as many apps as you can, making sure there is no dependency between them. It will allow you to benefit from the parallel build and deployment.

Update your Qovery configuration based on your application repository structure

Multi-stage deployment on the same environment

If within the same environment you have multiple applications using the same git repository and build context, you can benefit from the image caching mechanism provided by the mirriring registry by:

1. having one application X on a stage A. This is the one that will be built each time
2. having all the other application on other stages as long as they are after the stage A. For all these applications the build phase will be skipped since the image has already been built from application X

Managing Preview environments

No real configuration change is required here to speed up your deployment. Ensure to avoid as much as you can to use environment specific variables as ARGS within your Dockerfile (such as QOVERY_ENVIRONMENT_ID) since this will force a new build on each environment.

Cross-environment deploy with auto-deploy enabled

When the auto-deploy feature is enabled and you deploy the same application across multiple environments, the applications will be built separately on each environment and you can't benefit from the caching mechanism available for the already built images.

A small diagram to explain it:

Example: two apps A and B are configured on Qovery pointing to a repo X.

Flow: 1. A commit is pushed on the repo X. Git(hub/lab) inform Qovery about the new commit 2. Qovery starts the deployment of the two apps separately and checks the existence of the image. At this moment, the image does not exist and thus both deployments move forward with the build phase. 3. Qovery starts building the image for each application and pushes it onto the repository.

As you can see, every deployment is independent and the build choice is only based on the existence or not of the image on the container registry at the very beginning.