After you have installed and configured Deployment Automation, log in to the web application.
Get started by configuring and running a simple deployment. See the helloWorld deployment example for a walk-through or visit the Serena Deployment Automation Community to get pre-configured processes that you can import and run.
Although there is no set order, a typical sequence for configuring Deployment Automation elements and deploying artifacts is as follows:
Create components and set your source configuration type and version import approach. The source configuration type points to where the artifacts for which you are defining the component are stored, and you can choose to import the artifacts into Deployment Automation CodeStation automatically or manually.
Create and design component processes, defining the processes you want performed on target machines before, during, and after deployment of the component artifacts.
Create and configure environments, assigning resources, such as agents, to environments.
Create and configure pipelines, sequencing environments and adding approvals.
Create an application, selecting the pipeline it will use.
Add components to the application.
Add any additional environments to the application that are not included in the pipeline and map components to the environment resources they will use.
Create and design an application process to control the deployment. An application process typically initiates multiple component processes.
Request the application process to deploy the components.
The Deployment Automation web application user interface enables you to create and configure the Deployment Automation elements and initiate the deployment of your component versions. You can only see and access elements for which you are authorized. The web application user interface is shown in the following figure.
See the following topics for more information on the user interface.
The navigation bar appears along the top of the user interface. This gives you access to common actions.
The Home page of the user interface appears when you select Home in the primary navigation bar.
| Left Navigation Option | Includes Options Such As |
|---|---|
| Dashboard | View current activity |
| Calendar | View the process schedule |
| Work Items | View your work items |
| Reports | View provided reports on deployment and security and additional reports you have created |
The Management page of the user interface appears when you select Management in the primary navigation bar.
| Left Navigation Option | Includes Options Such As |
|---|---|
| Components | Create and import components and component templates |
| Applications | Create and import applications, add pipelines, environments, and components to applications |
| Environments | Create environments |
| Pipelines | Create pipelines |
| Configuration | Work with application, component, and environment properties and associations in context of the hierarchy |
| Processes | Create and import generic processes |
| Resources | Create resources |
The Administration page of the user interface appears when you select Administration in the primary navigation bar.
| Left Navigation Option | Includes Options Such As |
|---|---|
| Automation | Load plug-ins, view locks, configure post-processing scripts, set statuses |
| Security | Configure user authentication, group authorization, default permissions, tokens, roles, system security, and UI security |
| System | Configure licenses, network relay, notification schemes, output log, system properties, system settings, and import or export a full set of Deployment Automation objects using Replication |
Components represent deployable items and have user-defined component processes that operate on those items, usually by deploying them. Deployable items are artifacts associated with a software project, such as files, images, databases, or configuration materials. Components typically map to a functional part of a real world application, and have versions, which are used to ensure that proper component instances get deployed.
When you create a component, you identify the source and define how the artifacts will be brought into Deployment Automation. The artifacts can come from a number of sources, such as file systems, build servers such as Jenkins, configuration management systems such as Dimensions CM, source control systems such as Subversion and PVCS, and Maven repositories. Each component represents artifacts from a single source.
Upon automatic or manual version import, Deployment Automation imports the component's artifacts into the Deployment Automation artifact repository, CodeStation. This stores component versions.
Components include the following:
A component process is a series of user-defined steps that operate on a component's artifacts. Each component has at least one process defined for it and can have several. Component processes are executed by Deployment Automation agents running on hosts. One instance of a component process is invoked for each resource mapped to a component in the target environment.
You create component processes using Deployment Automation's process editor. The process editor is a visual drag-and-drop editor that enables you to drag process steps from a menu of standard steps onto the design space and configure them immediately. As you place additional steps, you visually define their relationships with one another.
Component processes may have only one step or may have many steps and relationships. They may also have conditional steps, or switch steps. When you initially implement Deployment Automation, you will typically use these process steps to replace existing deployment scripts and manual processes.
You can choose from several default utility processes, such as Acquire Lock, Join, and Set Status. You can select from a list of over 65 provided plug-ins, which provide support for many common processes, such as downloading and uploading artifacts and retrieving environment information.
An example process is shown in the following figure.
Figure 1. A Component Process in the Process Editor
Plug-ins provide basic processing functions as well as integration with third-party tools. Deployment Automation ships with plug-ins for many common deployment processes, and others are readily available for a wide variety of tools, such as middleware tools, databases, servers, and other deployment targets.
Plug-ins break down a tool's functions into simple, discrete steps such as detecting if a server is stopped, stopping a server, and starting a server. When you use plug-ins to create a component process, you typically use steps from several plug-ins. For example, you might create a process using a plug-in for a source control tool that deploys a component to a middleware server, and another plug-in to configure a step that removes the component from the server.
For a reference of plug-ins and examples of component processes using plug-ins, see the Serena Deployment Automation Plug-ins Guide.
After defining a component's source and processes, you import its artifacts into Deployment Automation's artifact repository, CodeStation. Artifacts can be imported automatically or manually.
By default, a complete copy of an artifact's content is imported into CodeStation. The original artifacts are untouched. This provides tamper-proof storage and the ability to review and validate artifacts with the Serena Deployment Automation user interface. If you have storage concerns or use a tool like Maven, you can limit CodeStation to using references to the artifacts instead of actually copying them.
Each time a component is imported, including the first time, it is versioned. Versions can be assigned automatically by Deployment Automation, applied manually, or come from a build server. Every time a component's artifacts are modified and re-imported, a new version of the component is created.
A component may have several unique versions in CodeStation. A version can be full or incremental. A full version contains all component artifacts; an incremental version contains only the artifacts modified since the previous version was created.
Applications bring together components with their deployment targets and orchestrate multi-component deployments. When you create an application, you identify the included components and define an application process.
You can create a snapshot to capture the application's current state, and as the application moves through different environments, the snapshot ensures that proper component versions are used.
Applications include the following:
Application processes, like component processes, are created with the process editor. Deployment Automation provides several common process steps. Otherwise, application processes are configured 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 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. 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, you can associate the application with a pipeline, or you can associate individual environments 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. Deployment Automation tracks the history of each component version, which enables application processes to restore environments to any desired point.
A snapshot is a collection of specific component versions, usually versions that are known to work together. A snapshot captures the application's current state, and as the application moves through different environments, the snapshot ensures that proper component versions are used.
Snapshots help manage complex deployments, such as deployments with multiple tiers and development teams. For example, after testing and confirming that team A's component works with teams B's, a snapshot can be taken. Then, as development progresses, additional snapshots can be taken and used to model the effort and drive the entire deployment, coordinating versions, configurations, and processes.
Typically, a snapshot is generated in an uncontrolled environment, meaning one without approvals.
An environment is a user-defined collection of resources that host an application. Environments are typically modeled on some stage of the software project life cycle, such as development, QA, or production. Environments can have different topologies. For example, an environment can consist of a single machine, be spread over several machines, or be spread over clusters of machines. Environments are mapped to agents, which manage resources.
Environments are created at the global level and used by multiple applications. This enables IT organizations to use shared or application-specific environments. Deployment Automation maintains an inventory of every artifact deployed to each environment and tracks the differences between them.
After you have created environments, you can create pipelines, which are sequences of environments where application process requests are propagated.
Environments include the following:
Agents are physical resources for the deployment and are installed on the target server. To run a deployment, Deployment Automation requires an agent on the target server. Typically, an agent is installed in every environment that an application passes through.
An agent is a lightweight process that runs on a target server and communicates with the Deployment Automation server. Agents are integral to the client/server architecture. Agents perform the actual work of deploying components and so relieves the server from the task, making large deployments involving thousands of targets possible.
Process requests, such as deployments, are orchestrated by the server and performed by agents distributed throughout the network. Server-agent communication is built around transferring, or deploying, components.
Figure 1. Simple Server-Agent Communication
Agent relays are used to manage communication between servers and agents when agents are dispersed across geographic locations or communicate through firewalls. Agent relays can also be used to manage network traffic in implementations where you have many agents.
Figure 1. Simple Agent Relay Communication
Copyright © 2011-2015 Serena Software, Inc. All rights reserved.