Share this page
Deployment Management terms and concepts
This topic introduces the terms and concepts in Deployment Management.
Standard interface and PPM Workbench
Deployment Management provides two different interfaces for working with packages.
-
Standard interface: Provides the Deployment Management package detail page. From a package detail page, and with the required permissions, you can process a package through its workflow. You can add notes and references to the package and make decisions about package status. However, from a detail page, you cannot add package lines. You cannot submit, change, or delete a package.
For instructions on how to create and submit packages to deploy software and application changes, see Create packages.
-
PPM Workbench: Opens the Package Workbench which is designed for engineers or developers to add package lines and submit a package. Creating and submitting packages requires specialized knowledge. In some cases, it requires passwords to production servers.
For information about the licenses and access grants required to work with packages in Deployment Management, see Security model. For information on how to move packages through their associated workflows, see Process packages. For instructions on how to work with (copy, cancel, merge, and so on) packages, see Manage packages.
Packages and object types
Packages are the fundamental work units of Deployment Management. A package consists of the objects that are processed through a business workflow.
While each package line can be acted upon separately, the group of package lines and objects represent a logical unit that should be moved and tracked together. The processing of a package and package lines can vary greatly depending upon the workflow specified for that package.
Each object belongs to an object type. An object type can also have associated commands that determine its behavior as it moves from one environment to another. Commands are used to define what a migration means for each type of object. For example, a File Object Type might only require that a file be copied, while a Database Script Object Type might require the copying of a file and executing it against the destination database.
Object types are user-configurable. Deployment Management and its extensions also provide libraries of predefined object types, falling under one of the following categories:
-
Standard Objects. Standard objects are predefined object types that are shipped with Deployment Management or one of the Deployment Management Extensions. These object types encapsulate the basic functionality that manages crucial actions. For example, migrating and executing file system-level objects and operating system commands, or applying patches to an Oracle applications instance. A standard object type is the File Migration object, which copies a file from one environment to another. A more complex standard object type is the SQL Script, which not only copies the file but also runs the script against the destination database.
-
Custom Objects. Customers must often customize standard object types, or produce entirely new object types, in order to handle the requirements of their software environments and deployment management processes. A custom object category is provided to help distinguish these customized object types from those that come with Deployment Management or its extensions. Such object types, designed by the customer or by consultants, are often used for integration with third-party tools or in-house products.
-
PPM Migrator Objects.PPM migrator objects are object types that contain functionality to export and import configuration information. You can use these for several purposes, including:
-
To transfer configuration information between distinct PPM instances
-
To extract information from a PPM database schema into an XML file
-
To load information from an XML file into a database schema
This means that you can migrate configuration information using standard deployment management test practices, processing a package through a workflow.
-
Workflows and workflow steps
A workflow consists of a logical series of steps that define the path to be followed by objects in a package. Workflow configuration and routing can be customized, and the workflow engine can handle virtually any business practice. This allows a department to generate workflows to automate existing processes, rather than forcing users to adopt a new set of processes to perform their work.
Workflow steps can range in usage from functional approvals to actual migrations. For example, migration steps automatically move specified objects from source environments to destination environments.
Workflow steps are events that are linked together to form a complete workflow. Deployment Management includes the following types of workflow steps:
| Workflow step type | Description |
|---|---|
| Decision workflow steps | In decision workflow steps, users must indicate the result or outcome. For example, work is approved or a review is completed. |
| Execution workflow steps | In execution workflow steps, the system performs an action and updates the step with result. Actions can range from calculating calculating a token value to copying files, running programs, or updating web pages. |
| Condition workflow steps | Condition workflow steps are logic steps used for complex workflow processing. For example, allowing a workflow to proceed only after all prerequisite steps are completed. |
| Subworkflow workflow steps | Subworkflow steps are entire workflows used as subworkflows. Subworkflow steps save time by incorporating predefined procedures into business process models. |
Releases
In Deployment Management, you can configure releases to group packages and related requests that must be deployed together. For example, the software company XYZ Corporation has a product update release scheduled for five months from now. To ensure successful product delivery, they decide to use Deployment Management to create a release that lets them track all changes to their original code.
As developers complete their packages, the packages are included in the release and processed together. Because every required change is grouped in the release, the company can quickly and easily assess the product status and progress toward delivery.
For details about releases, and how to create and configure them, see Demand Management configuration.
Deployment Management Environments
An Deployment Management environment is composed of a unique combination of server, client, database, and file system data that represent one logical group.
The environment server represents the main host machine for the environment. This machine may be of any platform type such as UNIX or Windows. Typically, the server is a UNIX machine that also hosts the database for this environment.
The environment client represents a remote client machine that also serves to identify the specified environment. The client is typically defined if users are doing multi-platform development in a client/server environment, with some development done on UNIX, and some on Windows Server. The client can be a file server that stores client code accessed by users. Many programs, such as transactional forms, have both client and server components; for example, the user interface code and the database objects, respectively.
Integrate Deployment Management
Deployment Management can be integrated with other products. This section provides the details.
