Workflows 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 and Component Workflows are used to deploy the individual components. You can define your Component Workflow quickly with pre-defined Actions.
What is a Workflow?
Workflows describe how deployments are carried out in the context of the Deployment Model.
In ARA 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 schedule them to run at a specific time. You can monitor the executions to see how they are progressing and even take action to influence the execution process, such as rolling back to a specific task, when the execution fails or gets held up.
Workflows can and should be designed to operate independently of the target environments and nodes.
Overview
Purpose: the purpose of Workflows is to deploy an Application's Components to their designated endpoints in a structured, efficient and orderly fashion. Workflows are fairly intuitive: they are a collection of processes related to deployments and submitted to the hosts. The 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 required to deploy that Component.
Operation: when the Workflow is executed these Actions are submitted in sequence to the AE Agents along with the necessary parameters. The Agents, in turn, execute the underlying system commands. We recommend incorporating efficiency in your Workflows by deploying Components in parallel as long as there are no dependencies between them. E.g. you can deploy your webapp to an Application server and a Database to a SQL server instance at the same time.
Characteristics: Workflows are fairly simple to build: they have an absolute starting point, an absolute end and Component Action couples in between.
Data map: we recommend avoiding the General Workflow type, that only contains actions but no components and is only appropriate for deployments that pertain to internal AE and ARA processes.
For more information see Workflow Types.
Workflow Structure
Workflows are layered structures along the lines of 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. In order to design workflows you need to drill-down into the sub-layers until your overall construct does exactly what you need.
ARA provides the following types of Workflows:
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 to monitor, application workflows are made up of two kinds of workflows:
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 new instance.
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 frontend, backend and database component. Each should be as independent from the other, so that only the components that have been updated need to be deployed.
This workflow contains all the technical processes that are part of that specific action.
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 ARA object model. They are used for generic ARA processes only (like checking an internal ARA 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 alongside other tasks, or for user-triggered maintenance tasks. General Workflows do not belong to any Application.
For more information on how to manage General Workflows see Workflow Definition — Overview.
Workflow Definitions and Custom Types
All workflow definitions are stored in objects and are assigned an ARA type that represents one of two base types "application" or "general." The workflow custom types that are delivered with the ARA application are:
You can use these or create your own custom types instead or in addition to these.
Individual steps or actions include, but are not limited to:
Topics