When you create an application, you identify the included components and define an application process. Application processes, like component processes, are created with the process editor. Serena Release Automation provides several common process steps, otherwise application processes are assembled from 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 instance, an n-tiered application might have a web tier, a middleware tier, and a database tier. And, continuing the example, 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. An environment is a collection of one or more resources. At least one environment must be associated with the application before the process can be executed. Application processes are environment agnostic; 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 (a typical scenario), you associate each environment with the application and execute the process separately for each one.
In addition to deployments, several other common processes are available, such as rolling-back deployments. Serena Release Automation tracks the history of each component version, which enables application processes to restore environments to any desired point.
