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.

Overview

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

There are three types of Packages:

• Deployment Package

  Specific Snapshot (set of values) of the Dynamic Properties of an application deployment model, including the dynamic properties of the application entity itself and one, several or all of the components the application is comprised of.

• Patch Package

  Always relates to a (previously installed) Deployment Package.

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

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:

• Package State

  Location in the Stateflow that can be transitioned to. Required.

• Package Transition

  Movement between states. Required.

• Folder Change

  A folder can be changed once the Package moves into a new Environment to reflect change of access rights to the package. Folders are important for the permission concept in Continuous Delivery Automation as they define actions a user can do on or with a Continuous Delivery Automation entity.

• Owner Change

  Change of ownership of the Package.

• Automated Deployment Workflow Execution

  An automated Deployment Workflow will be triggered for the required environment.

• Automated Build Workflow Execution

  An automated Build Workflow will be triggered for the required environment.

Basic Stateflow WITH States and Transitions

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

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.

Note: Stateflows should always include Transitions.

Why Transitions States Should Always be Used

There are two major reasons to use Transition States:

• Non-automated Package State Change

  If the workflow does not contain an automated Package State Change after a successful deployment, the Package would remain in the Deploy to Dev state, which is not accurate from a reporting perspective.

• Automated Package State Change

  If automated workflow executions are assigned to the Deploy to… states, these workflows will need an end action (upon successful completion of the deployment) that changes the Package State to the next Deployed to… state. The deployment duration time can be measured by the time spent between the two 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:

• Build Server creates Package – build server builds packages

• Build Server triggers Continuous Delivery Automation Package State Change – if the Build was successful, a post-build step can trigger Continuous Delivery Automation to change the Package State

• Package State Change triggers Automated Deployment – if the Package moves into a Deploy to… state the automated deployment is started

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

• DEV – DEV team owns the Development (CI) environments.

  After a Package has been created, the DEV team will initially be the owner of that Package.

• QA – QA team owns the QA environments.

  If a Package is moved to QA, the QA team will become the owner of that Package.

• RM – RM team is responsible for deployments to the PROD environments.

  If a Package is moved to PROD, the RM team becomes the owner of that Package.

External factors:

• A Build Server (or another external source) creates a new Package, which is initially set to Ready for DEV.
• If the build is successful for a specific Environment, the Build Server executes a Post-Build step to change the Continuous Delivery Automation Package state to Deploy to …. This triggers a Continuous Delivery Automation Deployment Workflow to the required Environment.

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:

• Deploy to DEV

  The red circle indicates that an automated deployment is executed.

  The end action of this deployment workflow changes the state to Deployed to DEV.

• Move to QA

  Once a user from the Development team decides that the Package should be handed over to QA, the user transitions the Package by applying Move to QA either in the Continuous Delivery Automation UI or through API (for example, if triggered by some ITSM Change Management Tool).

• Ready for QA

  If the Package moves Ready for QA, the folder is changed to the Application QA folder <APP>_QA. Also the owner should be changed to highlight who is in charge of the Package.

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:

• Control the deployment of specific builds (by labels/tags)
• Control the build and deployment times.

The following steps are usually performed in this scenario:

• ARA Package State Change triggers Build Server – moving the Package to the required Package State kicks-off a Workflow that triggers the Build Process on the Server.
• Build Server builds Package – the Build Server executes the Build and creates a physical Package that can be deployed.
• Successful Build triggers Continuous Delivery Automation Package State Change – once the Build Action in the Continuous Delivery Automation Workflow is finished, a Continuous Delivery Automation action changes the Package State.
• Package State Change triggers Automated Deployment – this automated Package State Change then triggers the automated Deployment.

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

External Factors:

• Build Server is orchestrated through Continuous Delivery Automation.
• No Post-Build step is required within the Build Server to change the State to "Deploy to...", this will be handled by CDA.

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:

• Build DEV Package – once the Package is moved to the Build DEV Package State, a build workflow is triggered, which kicks-off an external Build Job that creates a Deployment Artifacts for the Development Environment. The workflow waits for the Build Job to finish. If the Build Job finishes successfully, an out-of-the-box action changes the Package State to Deploy to Dev.
• Deploy to Dev – reaching this state, an automated Deployment workflow is triggered that deploys the Package to the Development environment. At the end of a successful deployment, the Package is moved to Deployed to DEV.

  This process of re-building and re-deploying can then be repeated as transitions were created that allow the user to repeat this process.

• Deployed to DEV and Ready for QA – these states are identical to the above scenario.

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.

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: