Workflow Best Practices
This page includes the following:
The following conventions are best practices for naming your Workflows. [WORKFLOW] denotes the basic name of the Workflow. If you need more granularity, describe specific functionality with a suffix. Use a Workflow name that describes its function, such as "Release Deployment", "Hotfix Deployment" or "Un-Deployment":
[WORKFLOW][Specific Process]
To distinguish untested or unreleased versions of Workflows (in development or test) from released ones, create additional _TESTING Workflows and create actions there:
[WORKFLOW]_TESTING
Add the changes to the main Workflow after you have tested the changes, either by copying a Component or manually adding the changes.
You can define and implement a general Workflow to execute a specific set of instructions which may not be deployment-related, such as obtaining specific release properties and executing some Application Workflows that match a specific set of profiles. Give general Workflows a name that describes what it is. When you create Workflows that are specific to an Application, include the Application name in the name of the Workflow:
[Application][WORKFLOW][Specific Process]
Ideally, you should only include Component Workflows in an Application Workflow. You can also use special Components, such as staging tasks.
These Components do not directly reflect Application Components, but are used for logical grouping of certain related activities in the process. Map these Components to special deployment targets, which are not used as the endpoints in a deployment process (= the servers or nodes "receiving" deployment artifacts and running deployment steps). Including other objects is not recommended.
Examples: A deployment target that represents a staging server, or deployment targets that represent nodes on which preparatory steps for the deployment are performed.
Multiple Instances of Components
Sometimes, you may need to add multiple Component Workflows as instances of the same Component to the same Application Workflow. This is the case when Dynamic Properties defined on a Component are used for several steps in the deployment.
Application Workflow Activities
An Application Workflow contains Component Workflows. An Application Workflow typically has only one main purpose. The following scenarios are examples of such purposes:
- Deploy a new release
- Deploy a hotfix
- Provision a new Application environment to un-deploy a release
- Provision a release from scratch to a new AWS environment
When you create multiple Workflows for the same Component, create an alias for each Workflow that describes what that particular Workflow is used for. Just like commenting scripts, this helps others understand exactly what that Workflow should be doing and makes it easier to debug a Workflow if it blocks or fails.
Each Component Workflow should represent a particular deployment process for an Application Component. Similar to Application Workflows, create Component Workflows by major use case, such as the following examples:
- Release deployment
- Undeployment
- Scratch installation
- Component provisioning
Application Components are created per:
- Node type or tier, such as frontend nodes or Application server nodes or database server nodes
- Different types of deployment artifacts, which require different deployment processes even if installed on the same node
- Logical groups of steps or activities required to prepare a deployment, for staging or for deployment validation
Keep logical dependencies between the deployment of Components to a minimum, so that you can deploy Components independently of each other.
In a CDA Workflow, dynamic properties are accessed via Components. This means a dynamic property must be present on the Component to be used within the associated Component Workflow. This dynamic property can then reference dynamic properties on other objects, such as packages or environments.