Application processes typically initiate component processes defined for their associated components.
Application processes can run manually, automatically on some trigger condition, or on a user-defined schedule. When a component has several processes defined for it, the application determines which ones are executed and in which order. For example, an n-tiered application might have a web tier, a middleware tier, and a database tier. The database tier must be updated before the other two, which are then deployed concurrently. An application can orchestrate the entire process, including putting servers on- and off-line for load-balancing as required.
When an application process executes, it interacts with a specific environment. At least one environment must be associated with the application before the process can be executed.
Application processes can be designed independently of any particular environment. This enables a single application to interact with separate environments, such as QA or production. To use the same application process with multiple environments, you can associate the application with a pipeline, associate individual environments with the application, or a combination of both.
In addition to deployments, several other common processes are available, such as rolling back deployments. Deployment Automation tracks the history of each component version, which enables application processes to restore environments to any point.
Application processes can be initiated as part of deployment packages to run multiple-application deployments. See Managing Deployment Packages.
For information on creating and designing application processes, see the following topics:
- Creating Application Processes
- Designing Application Processes
- Application Process Step Details
- Adding Application Process Properties
- Running Application Processes