About Packages

Deployment Management automates the migration and deployment of software code, configurations, and content. These objects are grouped into packages and are routed along business processes (workflows) using the PPM Workbench and the standard interface. Workflows automate the movement of each package through their required steps.

For example, you want to copy an operating system patch from the development environment, Dev, to the test environment, Test. After the operating system patch is thoroughly tested, you can copy the patch to production environment, Prod.

Figure 2-1. Package processing in Deployment Management

A package is the fundamental work unit of Deployment Management. Each package follows a workflow (business process). As with any business process, decisions are made and actions taken that affect the package. Each decision or action becomes a workflow step.

If a decision on a package is required, you must manually update a workflow step to reflect that decision. However, you can configure some actions (for example, migrating a file from one environment to another) to occur automatically. The basic components required to configure a workflow step to automatically migrate a file from one environment to another environment are as follows:

  • A package, which defines the file name, location, and type, and the workflow to apply.

  • A workflow, which determines the conditions that trigger file migration (workflow step), and the source and destination environments for the file migration.

When you create a package, you assign it a single workflow that defines the steps the package must take. Figure 2-2. Package workflow and workflow steps shows a sample workflow, with the following steps:

  • Approve Package

  • Dev to Test (migration)

  • Test Package

  • Test to Prod (migration)

  • Exit

Figure 2-2. Package workflow and workflow steps

You must perform the Approve Package and Test Package workflow steps manually during the course of the workflow. You configure the Dev to Test and Test to Prod workflow steps to run automatically.

Note: To assign a workflow to a package, you do not need to know how to configure a workflow step, or even a workflow. However, you do need to know how to access the information in a workflow, workflow step, and environment.

In Figure 2-3. How a package comes together , the package displayed in the Package Workbench is associated with a workflow in the Workflow Workbench. The migration workflow steps are configured with source and destination environments. You access and configure environments using the Environment Workbench.

The package in Figure 2-3. How a package comes together is configured with a single package line, and then configured with an object type. A package line can contain only one object type. The object type contains the information required to migrate a file (an object), including the file name, location, and type (ASCII or binary). Depending on the object type definition, additional information may be required.

Figure 2-3. How a package comes together

Object types are defined in the Object Type Workbench. In the Object Type Workbench, you can open and access the command sequence used to migrate the object across environments. These command sequences include special commands defined in the Special Command Workbench.

To create a package, you must know the following:

  • Workflow. Defined in the Workflow Workbench.

  • Environments.Specified in the workflow step and defined in the Environment Workbench.

  • Object type.Defined in the Object Type Workbench.

For information about the licenses and access grants required to work with packages in Deployment Management, see the Deployment Management Configuration Guide.