Deployment Packages

A Deployment Package is an instance (a version, a revision, a tag, …) of an Application that defines the content that will be deployed (either the entire application or simply a few specified components). It has a life-cycle that consists of states and the transitions between states and that is defined by Package Stateflows. This topic describes Deployment Packages and their life-cycle and two scenarios to help you understand their usage.

This page includes the following:

Overview

A package bundles the components that contain the actual functionality (new and changed). See: CDA Deployment Model.

There are three types of Packages:

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

Graphic depicting role of packages  in deployment model

Package Stateflow

Package life-cycles are defined by Package Stateflows. They specify the path that the Package has to follow through different stages and environments in the delivery pipeline, that is, its states, the transitions between states and their (change of) ownership. They are fully customizable. This means that you can add to them steps that are performed outside CDA.

Package Stateflows can automate the entire CD & CI process, from automated build through to deployment and testing. On each transition, actions can be performed, such as automatically executing workflows.

The following graphics describe Stateflows. They use these symbols:

Graphic depicting stateflow

Basic Stateflow WITH States and Transitions

A basic stateflow consists of States and Transitions. For example:

Graphic depicting basic stateflow with states and transitions

Basic Stateflow WITHOUT States and Transitions

In the example below there is a direct movement from Deploy to Dev to Deploy to QA without a transition state. This is not best practice as the package has to be handed over from one team to another.

Graphic depicting  basic stateflow without states and transitions

Note: Stateflows should always include Transitions.

Why Transitions States Should Always be Used

There are two major reasons to use Transition States:

Scenario 1: Build Server Orchestrates Continuous Delivery Automation Deployment (Automated Deployment)

This scenario is typically used in the context of a Continuous Integration system with Continuous Delivery Automation deployments being triggered upon successful builds (for example, Jenkins).

The diagram below describes the whole process:

Graphic depicting delivery process

In this scenario, three teams are involved in the delivery process.

External factors:

Package State Description:

In this example, the Build Server creates a new Build for the Development (CI) Environment. A Post-Build step within the Build Server checks if the Continuous Delivery Automation Package already exists. If does not exist, it creates a new Package. If it exists, it changes the Package State to Deploy to DEV.

This is what happens on the different states:

Graphic depicting automated deployment stateflow

Scenario 2: Continuous Delivery Automation Orchestrates Build Server (Automated Build & Deployment)

In this scenario Continuous Delivery Automation orchestrates a Build Server. This scenario may be helpful if you want to use Continuous Delivery Automation to orchestrate the Continuous Delivery process to:

The following steps are usually performed in this scenario:

Graphic depicting delivery process

Let us assume the same three teams are involved in the process as in the previous scenario.

External Factors:

Package State Description:

In this example, a new Package is created first. This could be done in the Continuous Delivery Automation UI or through external integration, for example, a trigger from a version control system (a certain baseline tag). The Package state has to be changed to Build DEV Package or Deploy to DEV depending on the requirements. This Package State Change can be triggered by an external technology (ITSM System) such as ServiceNow or BMC Remedy or it can be changed via the Continuous Delivery Automation UI.

The following steps are considered in this example:

Provisioning and Deployment

The Continuous Delivery Automation Package Stateflow could be also used to take care of provisioning and deployments through the CDA provisioning functionality. In the example below, the Package Stateflow is used to provision Environments before the deployments. This could be done for Non-Prod environments only, or for the full stack of environments.

Graphic depicting automated provisioning and deployment stateflow

Installations

CDA also keeps an inventory of which packages and specific components within have been deployed to which environments and deployment targets and in which sequence (see also Viewing Package Installations).

Example of a Deployment Package

The value of a dynamic property representing the location of the deployment artifacts of a specific build of an application in a version control system could be set on package-level.

A package per software version of the application can be used. The component artifacts must not necessarily be contained in the package but they can reside somewhere else.

Packages can also be used to represent specific configurations of the application. For this purpose, configuration settings (including for example, locations of configuration files or other configuration objects) can be modeled as dynamic properties, which receive their target value on package-level.

See also: