Skip to content
CA Continuous Delivery Director - Integrations
Documentation powered by DocOps

Continuous Delivery Automation Plug-in

Last update February 27, 2019

Release automation is a key component of your continuous delivery pipeline. The Continuous Delivery Automation (CDA) plug-in, (formerly known as Automic Release Automation or ARA) enables you to apply core CDA deployment modeling (applications, environments, and so on) and deployment capabilities.

This plug-in lets you start both Application and General workflows directly from the CA Continuous Delivery Director user interface.

This plug-in is available for both CA Continuous Delivery Director on-premise and CA Continuous Delivery Director SaaS. To work with CA Continuous Delivery Director SaaS, enable a plug-in proxy.


Supported Versions

The CDA plug-in supports CDA 12.0 and above.

To learn more about CDA, see the CDA product documentation.

Capabilities

The CDA plug-in lets you do the following activities:

  • Import applications and environments from an CDA instance. You can include all CDA applications and their environments in releases, phases, tasks, reports, and widgets.
  • Start a workflow in CDA from a task in a release.

Install the CDA Plug-in

Follow these steps:

  1. Download the CDA plug-in from the Automic Marketplace (https://marketplace.automic.com/).
  2. Extract the .war file to the webapps directory of the Apache Tomcat server.
  3. Log in to CA Continuous Delivery Director.
  4. Select the ADMINISTRATION tab and Plug-ins.
  5. Select Register Plug-in in the top-right corner.
    The REGISTER PLUG-IN dialog is displayed.
  6. Enter the manifest URL of the plug-in in the following format: http://<plugin-server>:<port>/cdd-ara-plugin/manifest.json.
  7. Select Register to start the installation process.

Add the CDA Endpoint

Follow these steps:

  1. Select the ADMINISTRATION tab and select Endpoints.
  2. Select Add Endpoint in the top-right corner.
    The ADD ENDPOINT dialog is displayed.
  3. Enter the following information:
    1. Name of the endpoint
      Example: Dev Instance
    2. Optionally, a description to better identify the endpoint.
    3. From the drop-down list, select one or more users you want to authorize for the endpoint.
    4. Select the ARA Endpoint plug-in.
    5. In the Input Parameters section:
      1. Enter the URL of your CDA (ARA) REST endpoint.
        Example: http://192.168.23.125/ara
        Note: The URL can be specified as http or https.
      2. Enter the credentials of a CDA user (username in the following format: client/name/department and password) with sufficient rights to execute an Application deployment.
  4. Select Test connection to verify that you can connect to the CDA (ARA) endpoint.
  5. Select Add

Import CDA Applications and Environments

You can import applications and environments from your CDA endpoint to be used in the continuous delivery orchestration pipeline.

Notes

  • Make any changes to applications or environments directly within your CDA instance.
  • CA Continuous Delivery Director converts any imported CDA environments with the same name to a single shared environment.

Import the required applications and environments from CDA before using this CDA plug-in.

Follow these steps:

  1. Select the ADMINISTRATION tab and Applications and Environments.
  2. Select Add External Applications. The ADD EXTERNAL APPLICATIONS dialog is displayed.
  3. Select the CDA endpoint (ARA).
  4. Select Import.

All the applications assigned to the login credentials you entered to grant access to your ARA instance are imported. For more information, see: Add the CDA Endpoint.

Workflows

In CDA, workflows are used to carry out physical deployments. A workflow describes all necessary steps for a deployment of your application.

Workflows consist of a set of tasks or actions, which are organized in a combination of sequential and parallel execution paths, which are combined with conditions, loops, pre-conditions, and post-conditions. Each action can run in parallel or sequentially for one or more deployment targets within an environment.

In CA Continuous Delivery Director, after you configure CDA workflows using the CDA plug-in, you can execute those workflows at any time or can schedule executions at a specific time. You can monitor the progress of the executions. You can also take action to influence the execution process, such as rolling back to a specific task when the execution fails or pauses.

The CDA plug-in supports the following types of workflows:

  • Application workflows
  • General workflows

Note: Application workflows are stored in folders with the application (no separate access control), whereas general workflows are stored in folders separately.

Application workflow

Application workflows combine and orchestrate different component workflows for a complete end-to-end application deployment. You can use application workflows for installations, updates and removal of one or more components that are involved in a deployment for a specific application. To provide a clear structure that is easier to build and to 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, such as installing a program, deploying an update or provisioning a new instance.
  • Component workflow
    Orchestrates the deployment of an individual component (or parts of a component) 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 these steps as the building blocks for the application deployment.
    For example, a website may have a frontend, backend and database component. Each component should be independent from the other components, so that only those components that have been updated are deployed.

General workflow

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

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

View CDA Tasks

You can only see tasks of releases that you are a member of.

  1. In CA Continuous Delivery Director, select the RELEASES tab.
  2. Select a release. The release design page is displayed, where you can see the phases and tasks that make up the release.
    For each task, the following information is displayed:
    • Task name
    • Task type
    • Status (only displayed if the phase the task belongs to has been executed at least once)
  3. Hover over the status of a running task to see additional information:

For more information about creating tasks, see How to design and create releases 

Create CDA Tasks

Follow these steps:

  1. In CA Continuous Delivery Director, select the RELEASES tab.
  2. Select Create a task... within the phase of your choice.
    The CREATE TASK dialog is displayed.
  3. Enter a task name.
  4. Optionally, enter a description to better identify the task.
  5. Assign one or more owners to the task.
  6. From the Task Type drop-down list, select one of the following CDA task types: Start General Workflows or Start Application Workflow.

    Unlike General Workflows, Application Workflows typically contain only one or more Component Workflows at their highest level. Each Component Workflow, however, contains objects and functions like a General Workflow. Component Workflows orchestrate the deployment of an individual component (or parts of it) on one or more Deployment Targets within an Environment.

    Start General Workflow
    The Start General Workflow task lets you run an CDA General workflow in the context of CA Continuous Delivery Director phases and releases. This task lets you orchestrate core CDA activities at a high level. For example, a release might include multiple applications that you can deploy through the CDA deployment model. 
    Follow these steps:

    1. Select the endpoint created to connect to the CDA instance.
      Example:Dev Instance
    2. Enter the General Workflow to be executed. The workflow value can be:
      • Selected from the list displayed after typing "@" in the field
        Example:Deploy Tomcat
      • Entered as a token (reusable placeholders used to create generic workflows) by typing "%" in the field and selecting an option from the list
        Example:last_successful_build
      • Entered as free text (alone or together with tokens)
    3. Optionally, enter dynamic properties and values. See Defining Dynamic Properties.
    4. Enter the Compensation Parameters. See Managing Compensation Workflows.
    Start Application Workflow
    The Start Application Workflow task lets you run an CDA Application workflow in the context of CA Continuous Delivery Director phases and releases. This task lets you orchestrate core CDA activities at a high level. For example, a CA Continuous Delivery Director release might include multiple applications that you can deploy through the CDA deployment model.
    Follow these steps:
    1. Select the endpoint created to connect to the CDA instance.
      Example:Dev Instance
    2. Enter the Application, Application Workflow, Deployment Package and Deployment Profile values. The values can be:
      • Selected from the list displayed after typing "@" in the field.
        Example: Deploy Tomcat
      • Entered as a token (reusable placeholders used to create generic Workflows) by typing "%" in the field and selecting an option from the list.
        Example:last_successful_build
      • Entered as free text (alone or together with tokens)
    3. Optionally, enter dynamic properties and values. See Defining Dynamic Properties.
    4. Enter the Compensation Parameters. See Managing Compensation Workflows.
    5. Select an installation mode:
      • Overwrite Existing: to deploy the Package on every target and overwriting existing components
      • Skip Existing: to only deploy the Application on targets where the deployment package has not yet been deployed
  7. Optionally, in the CONTENT panel, select the Application content you want to tie with the completion of the task to keep track of when and where the content is deployed.
  8. Select Create to create the task.

Defining Dynamic Properties

You can define dynamic properties and values in tasks.

Follow these steps:

  1. (Optional) Enter or select a dynamic property to be used as input parameters for the workflow execution.
    Dynamic properties and values can be:
      • Selected from the list displayed after typing "@" in the field.
      • Entered as a token by typing "%" in the field and selecting an option from the list.
      • Entered as free text (alone or together with tokens).

        Important! You must enter the full name of a dynamic property:

        • Component/{comp_name}/{dynamic_fullname}

        • Workflow/{dynamic_fullname}

        • Application/{dynamic_fullname}

        • Package/{dynamic_fullname}

    Note: Only prompts can be used.

  2. (Optional) Enter or select a value to be passed to the execution.
    Note:
    • Values can be referenced as follows:
      • Static value: string
      • Reference value: {“name”: “reference_name”}
      • Package, component reference value: { “name”: “reference_name”, “application”: {“name”: “app_name”}}
    • Values override dynamic properties.
  3. (Optional) Enter additional dynamic properties and values in JSON format.
    Dynamic properties and values can be:
    Example:

    { "application": { "/DYNAMIC_PROPERTY_FULL_NAME1": "STATIC_VALUE", "/DYNAMIC_PROPERTY_FULL_NAME2" : { "name":"REFERENCE_OBJECT_NAME", "application":{"name":"APPLICATION_NAME"} }

    Note: The dynamic properties entered in this field override the dynamic property values.

Managing Compensation Workflows

You define compensation workflows to be executed if a main workflow reaches one of the following statuses: rejected, revoked or canceled.

The status of the task is not set to failed if a compensation workflow has been defined.

Compensation Task Workflow


Compensation workflows can be defined for general and application workflow task types.

Follow these steps:

  1. Follow the steps described in the Create CDA Tasks section. Do not save your changes and proceed to the next step.
  2. Select the Compensation Parameters checkbox.
  3. Select the input parameters for the compensation task:
    • General Workflow: Workflow, Dynamic Properties.
    • Application Workflow: Application, Workflow, Package, Deployment Profile, Installation Mode, Dynamic Properties.
  4. Save your changes.

Output Parameters

In the Output Parameters section of a CDA task, you can specify the Execution ID and Run ID of the Workflow to be returned as a response. These values can be used in later tasks and phases.


Important!

Run ID and execution ID refer to different concepts. The run ID is generated by the Automation Engine when the execution starts. The execution ID is the key that uniquely identifies a deployment in CDA.

  • Execution ID: ID of the Execution.
    Use the % prefix and select a token.
    Example: %ExecutionID.
    Note: Built-in tokens such as last_successful_build are not supported.
    See also: Execution
  • Run ID: ID of the workflow in the Automation Engine.
    Use the % prefix and select a token.
    Example: %RunID.
    Note: Built-in tokens such as last_successful_build are not supported.

Executing Releases in CA Continuous Delivery Director

To learn about executing releases in CA Continuous Delivery Director, see Release Execution.

Important!

After running a CDA task (main and compensation workflows) in CA CDD:
  • Select the Open Installations link that is displayed for finished tasks (tasks with status failed or finished) to access the Installations view in CDA.
  • Select the Open Monitor link that is displayed for finished tasks (tasks with CA CDD status failed or finished) to access the Workflow Monitor in CDA.

Status Mapping

The CDA execution statuses are mapped to the CA CDD statuses as follows:

CA CDD Status CDA Status
RUNNING WaitingApproval
RUNNING WaitingStartTime
RUNNING WaitingManualConfirm
RUNNING Active
RUNNING Blocked
FAILED Rejected
FAILED Revoked
FAILED Canceled
FAILED UNKNOWN_EXECUTION_STATUS
FINISHED Finished



Was this helpful?

Please log in to post comments.