Table of Contents
Applications are responsible for bringing together all the components that need to be deployed together. This is done by defining
the different versions of each component as well as defining the different environments the components must go through on
the way to production. In addition, Applications also map the constituent hosts and machines (called resources) a component
needs within every environment.
Applications also implement automated deployments, rollbacks, etc. These are called Processes; however, at the Application level Processes are only concerned with the Components and Resources necessary for deployment, etc. -- differentiating Application-processes from those of Components (which are concerned with running commands, etc.).
Applications also introduce Snapshots to manage the different versions of each Component. A snapshot represents the current state of an Application in the Environment. Typically, the Snapshot is generated in an Environment that has no Approval gates -- called an uncontrolled Environment. For most users, the Snapshot is pushed through the pipeline.
Note
Before configuring an Application, you will need to ensure that at least one agent has been installed in a target environment (for evaluation purposes, the agent can be on the same machine as the server). In addition, you will also need to add at least one Resource Group to the agent. See Resources.
Environments
An Environment is a collection of Resources that host the Application. Environments typically include host machines and Serena Release Automation agents. When a deployment is run, it is always done so in an Environment. While Environments are collections of Resources, Resources can vary per Environment.
For example, Environment 1 may have a single web server, a single middleware server, and a single database server, that must be deployed to; Serena Release Automation represents these as three, separate Resources running in Environment 1. Environment 2, however, may have a cluster of Resources that the same Application must be deployed to. Serena Release Automation compensates for these differences with Resource Groups (more at Resources by keeping an Inventory of everything that is deployed to each Environment: Serena Release Automation knows exactly the Environment and Server(s) where the Application was deployed to: and tracks the differences between the Environments.
Processes
A process plays a coordination role. They are authored using a visual drag-n-drop editor, and composed of Steps that call the Component Processes. For example, to deploy the Application you may invoke a Process called Deploy. This Deploy Process would in turn call out to the requisite Components and execute the deployment.
Snapshots
Snapshots specify what combination of Component versions you deploy together. They are models you create before deploying the Application. A Snapshot specifies the exact version for each Component in the Application. When a Snapshot is created, Serena Release Automation gathers together information about the Application, including the Component versions, for a given Environment. Typically, the Snapshot is generated in an Environment that has no Approval gates -- called an uncontrolled Environment. For most users, the Snapshot is pushed through the pipeline. Typically, one of the Environment will always remain uncontrolled to allow for Snapshots. When a successful deployment has been run in the uncontrolled Environment, a Snapshot is created based on the Application's state within the Environment: thus capturing the different versions of the Components at that time. As the Application moves through various testing Environments, for example, Serena Release Automation ensures that the exact versions (bit for bit) are used in every Environment. Once all the appropriate stages and Approvals for a Snapshot are complete, the Snapshot is pushed to Production.
