Workflows

As an Application Developer, you create Workflows that are used to carry out physical deployments. A Workflow describes all necessary steps for a deployment of your Application. As your Application consists of different Components, the top level of the Workflow (Application Workflow) represents your Application architecture. The Subworkflows (Component Workflows) are used to deploy the individual Components. You can quickly define your Component Workflows with pre-defined Actions.

Overview

Note: The following illustrates the role of Workflows in the Deployment Model. Select the image to expand it.

Workflows describe how deployments are carried out in the context of the CDA Deployment Model.

In CDA, you can define Workflows to carry out the tasks in complex processes of release automation. Once you have defined Workflows, you can execute them at any time or you can schedule them to run at a specific time. You can monitor the executions to see how they are progressing and even act to influence the execution process, such as rolling back to a specific task when the execution fails or gets held up.

Note: Workflows should be designed to operate independently of the Environments and Deployment Targets.

Workflows deploy Application Components to their designated Deployment Targets in a structured, efficient, and orderly fashion. A Workflow contains all the Components to deploy and the sequence in which to deploy them. Each Component has a new Workflow that contains the sequence of Actions that are required to deploy that Component.

When the Workflow is executed, the Actions are submitted in sequence to the AE Agents with the necessary parameters. The Agents, in turn, execute the underlying system commands.

Tips:

• Incorporate efficiency in your Workflows by deploying Components in parallel as long as there are no dependencies between them. For example, you can deploy your webapp to an Application server and a Database to a SQL Server instance simultaneously.
• The General Workflow type contains only Actions but no Components. This Workflow type should only be used for deployments that pertain to internal AE and Continuous Delivery Automation processes.
  • Type General: no connection to other Entities because they have no Components.
  • All other types: Workflow requires (1) a Package and (2) a Profile.

Note: For more information, see Workflow Types.

Workflow Structure

Workflows are layered structures as in a Russian doll model. Each part of a Workflow contains a sub-level Workflow, and each part of a sub-level Workflow contains yet another sublevel. To design Workflows, you have to drill-down into the sub-layers until your overall construct does exactly what you need.

Workflow Types

CDA provides the following types of Workflows:

• Application Workflow

  Combines and orchestrates different component workflows for a complete end-to-end Application deployment. You can use them for installations, updates; and un-installations of one or more Components that are involved in a deployment for a certain Application. To provide a clear structure that is easier to build and monitor, Application Workflows are made up of two kinds of Workflows:

  • Application deployment Workflow

    Defines the overall process of an Application deployment by defining the Components which are deployed.

    An Application Workflow typically has only one main purpose, for example, installing a program, deploying an update or provisioning a new instance.

    

  • Component Workflow

    Orchestrates the deployment of an individual Component (or parts of it) on one or more Deployment Targets within an Environment. Here you define the steps for the deployment of a single Component of an Application. You can regard them as the building blocks for the Application deployment.

    As an example, a website may have a front-end, back-end, and database Component. Each should be as independent from the other, so that only the Components that have been updated have to be deployed.

    

    • Action Workflow

      This Workflow contains all the technical processes that are part of that specific action.

• General Workflows

  General workflows are available as an option for more generic tasks (as the name implies), such as a single start-point for larger-scale process automation, maintenance tasks, or for anything that does not require access to the Continuous Delivery Automation object model. They are used for generic Continuous Delivery Automation processes only (like checking an internal Continuous Delivery Automation resource). Typically, this would mean that any actions outside of a deployment would be executed here.

  General Workflows are most often used for the orchestration of multiple Application deployments beside other tasks, or for user-triggered maintenance tasks. General Workflows do not belong to any Application.

  Note: For more information about how to manage General Workflows see Designing Workflows (JOBP).

See also:

• Working with Workflows
• Creating Component Workflow Templates
• Creating Template Action Packs for Component Workflows
• Workflow Best Practices