Managing deployment rules

Edit online

Deployment rules in Db2® CI/CD Expert define how Db2 object definitions are handled during deployment to a target environment as part of a release. These rules ensure that deployments are tailored to the specific requirements of each environment. The types of deployment rules are translation, overwrite, directive, and ignore.

Types of deployment rules

You can define and apply the following four types of deployment rules:

  • Translation: These rules specify how to change attributes, such as names or schemas, of Db2 objects when they are deployed on the target environment.
  • Overwrite: These rules define which attributes of Db2 objects are to be set to new values at the target during a deployment.
  • Ignore: These rules indicate which Db2 objects or attributes are not to be compared between the source and the target during a deployment.
  • Directive: These rules specify specific operations, such as utility operations and reporting, to be performed during a deployment.

Db2 CI/CD Expert includes a set of default ignore rules at the global level. These default ignore rules are not automatically applied during deployment. You must explicitly include them in a deployment plan by setting addAllDefaultOwnershipIgnores to true. For the list of default rules, refer Default deployment rules in Db2 CI/CD Expert.

Important: Deployment rules created within Db2 CI/CD Expert are not applicable for DDL deployments from external repositories. They are applicable only for catalog-to-catalog deployments. For DDL deployment from external repositories, deployment rules are usually defined and managed in source control outside Db2 CI/CD Expert. These rules must be explicitly included in the request body during the CREATE deployment plan operation.

Rule intersections and precedence

You can define deployment rules at various intersections, determined by specific combinations of filters such as path, environment, landscape, and manifest. These intersections determine where and how a deployment rule applies within a release and establish its precedence.

When multiple rules exist, the rule with the most specific filter combination takes precedence over the more general ones. This means that a rule defined with more filters overrides a rule defined at a broader level. For example, a rule defined for a specific environment on a defined path for a specific manifest overrides a rule defined for an entire landscape that contains that environment.

The following is a list of deployment rule intersections, ordered from least to most specific, with the most specific (highest precedence) at the bottom:

Table 1. Precedence of rule intersections
Precedence Intersection type Translation rule allowed?
1 (lowest) Global N
2 Landscape Y
3 Landscape on Path Y
4 Environment Y
5 Environment on Path (node) Y
6 Manifest N
7 Landscape on Path + Manifest Y
8 (highest) Environment on Path + Manifest Y
Notes:
  • You cannot define translation rules at the Global or Manifest-only intersections. You can define overwrite, directive, and ignore rules at all intersections.
  • Rule intersections only apply to catalog-to-catalog deployments. For DDL deployment from external repositories, deployment rules are usually defined and managed in source control outside Db2 CI/CD Expert.

Example: Rule precedence in deployment intersections

This example illustrates how Db2 CI/CD Expert determines which translation rule to apply when multiple translation rules are defined for the same deployment environment.

wo translation rules are defined for the QA-DB environment:

  • Rule A: Defined at the environment-only intersection.

    • Applies to all deployments to QA-DB, regardless of the deployment path or manifest.
    • Translates table object names to the format TEST_*.

  • Rule B: Defined at the environment + path + manifest intersection.

    • Applies only when deploying to QA-DB using path P1 and manifest M1.
    • Translates table object names to the format QA_*.

How the rules are applied:

  • When a deployment targets QA-DB using path P1 and manifest M1, Rule B takes precedence and is applied.
  • When a deployment targets QA-DB using any other path or manifest, Rule A is applied.

Why Rule B takes precedence:

Rule B is defined at a more specific intersection (environment + path + manifest) than Rule A. when all conditions of a more specific rule are met, that rule overrides rules defined at broader intersections, such as Rule A (environment-only).