Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In

Drx product name
, so called Workflow Packages are used to facilitate the transportation of data between different environments, such as development, test, and production environments.

...

Using tools for traffic management there are also solid processes for doing “Blue/Green” or “Canary” deployments to achieve zero-downtime upgrades. See Upgrade Strategy for more information.

CI/CD pipeline steps

The picture below shows an example of the steps involved in a CI/CD pipeline. The third party products Git, Jenkins, and Artifactory are just examples.

...

  1. Development environment: Code is changed and workflows are built in a
    Drx product name
     development environment, where environment specific data such as EC Deployments, scheduling rules, and global parameters are also handled. When suitable, the developer exports the configured workflows to a central version control system, such as Git. The version control system is where test cases, configurations, workflows, and test data are stored. The export format is based on JSON and is structured in a way that makes it easy to track changes between versions. 

  2. Build and Test Server: Once workflows are ready, they are moved into a staging or integration environment. Here, workflows and other parts of the solution are compiled into packages and possibly assembled with pieces from other development environments. Automated test suites are automatically applied to the packages in this environment. When all tests are passed, an orchestrator (for example Jenkins) orders
    Drx product name
    , which acts as a build server, to create Workflow Packages (binaries). In our example, the package is created in the form of an archive zip-file including all needed components, such as Docker images and Helm charts. Workflow Packages can also be built manually directly from any
    Drx product name
     system. See Workflow Packages for more information.

  3. Docker image and Helm chart: At this point, the Workflow Package can be promoted to the next step. The Docker image contains all relevant information required for running in, for example, a pre-production environment. The Helm chart, located in a Helm repository, points out the Docker image, the Workflow Package version, and workflows.

  4. (Pre-)Production environment: The Helm chart pointing out the Docker image is deployed in a target environment, for example the pre-production environment. When suitable, the exact same procedure can be applied to a production environment. The configuration and workflows look exactly like in a development environment but are read only.

...

For information on how to install the example pipeline, see Install the Example CI/CD Pipeline.

This section contains the following sub-sections:

...