Deployment Rule

A Deployment Rules lets you configure the lifecycle of your Environments.

Why using Deployment Rule?

Cloud cost optimization

Using the Deployment Rules is a good practice to drastically reduce your cost. Indeed, Qovery knows how to optimize your Cloud resources when your applications are not running. Then you can expect to reduce your Cloud cost up to 60% by using the Deployment Rules.

Time optimization

Configuring your environments, managing, starting, shutting down all takes valuable time from your developers. Deployment Rules allow you to declaratively set up how your resources should be used, let Qovery do the dirty job, allowing your employees to focus on important things.

Examples

Shutting down environments

Developers in your company work from 9-to-5, five days a week. During the weekend, at night, and of the working hours, keeping all development environments running may be a huge expense that gives you no benefits.

Deployment Rules address this problem very effectively - all you need to do is to define when you need your environments to be running, and let us handle the rest. Qovery will start and stop your services for you to make sure your cloud spending is optimized and wise.

Using cheaper cloud providers

Running your development environments on expensive cloud providers might not be the best way to spend your money. Deployment Rules allow you to deploy your development environments to a cheaper cloud account while still keeping your production using the most reliable services provided by the more expensive cloud provider.

Rule Levels

You can set up your Rules at Project and Environment levels. Rules set up at the Project level will be automatically applied to newly created Environments you target in the rule. If, however, the default settings applied by the Project level rule does not meet your needs, you are allowed to override the settings at the Environment level later on.

Project Deployment Rules

Declaring deployment rules at the project level allows you to apply reasonable defaults to all newly created environments. After a new environment within a project is created, rules from the Project are applied to the Environment. However, to keep things flexible, Qovery allows you to override the rules after environment creation at the Environment level, in Environment settings.

Project Rules Configuration

1. Navigate to Console

2. Select your project

3. In the environment list, select the tab Deployment Rule and click Add Rule button:

   

4. Matching rule definition

   You will have to provide a rule name, description and a matching condition.

   Matching Condition - Environment Name

   This field allows you to specify which environments should be affected by the given deployment rule, based on their name.

   You can either enter the full environment name or use Wildcards.

   Wildcards

   Wildcards allows you to build regular expression to match the name of the environments you want your deployment rule to target.

   You can use the following characters to specify your rule.

   wildcard	behavior	will match
   ?	Any one character	"A", "B", "c", "z", etc.
   ??	Any two characters	"AA", "AZ", "zz", etc.
   ???	Any three characters	"Jet", "AAA", "ccc", etc.
   *	Any characters	"apple", "APPLE", "A100", etc.
   *th	Ends in "th"	"bath", "fourth", etc.
   c*	Starts with "c"	"Cat", "CAB", "cindy", "candy", etc.
   ?*	At least one character	"a", "b", "ab", "ABCD", etc.
   ???-??	5 characters with hypen	"ABC-99","100-ZT", etc.
   xyz	Contains "xyz"	"code is XYZ", "100-XYZ", "XyZ90", etc.

   For example, the rule Prod_Env_* will target the environment named:

   • Prod_Env_1
   • Prod_Env_feature

   But will not target the environment named: Staging_Env_1

   If you want to apply a rule to the preview envirionments, use the rule "[PR]*" (since every preview environment name will start with "[PR]")

   Setup to apply - General

   Mode (Deprecated)

   We are re-building this feature and thus you will always have to select a mode when creating a new environment

   You can automatically assign a type of environments based on his name.

   Cluster

   Selecting the cluster allows you to control to which cluster your environments in the project will be deployed to.

   Example use cases

   • deploy your development environments on a more cost effective cluster
   • deploy your environments in multiple regions

   We are re-building this feature and thus you will always have to select a clsuter when manually creating a new environment. This feature still works for preview environments.

   Setup to apply - Start & stop

   Start & Stop

   The start and stop section allow you to precisely set up when the environments inside the project should be deployed and cleaned up.

   Use cases examples

   • shut down your development environments during the weekend
   • deploy additional environments during peak hours
   
   

How was it? Did this tutorial work?  Yes  No

Rules priority

Since you can define several rules, it is possible that an environment is targeted by more than one of them. In order to define which rule applies first to your new environments, you can reorder the list of rules in the deployment setting window. Starting from the top, the rules are ranked from highest to lowest priority.

Environment Deployment Rules

Setting up Deployment Rules at the Enviornment level allows you to make all necessary adjustments applied by your default rules from the Project level.

Have a look at [this section][docs.using-qovery.configuration.environment#deployment-rule]] to know more.