Deployment Automation can be used in a simple configuration for individual teams. It can also scale to support enterprise-grade requirements: horizontal scalability, enterprise-grade security, performance, and high availability.
Deployment Automation has four primary components, and each can be logically and physically separated to support pre-existing, operationally-defined infrastructure requirements.
Stateless controller server(s) provide access to the security engine, workflow engine, user interface, and other key areas of the product. This tier can be fully load-balanced to enable almost instantaneous failover, allowing both high-availability and load-balanced implementations. User access is available via command line, RESTful service, or browser-based user interface (UI). All system configuration, process definition, deployment, and reporting capabilities are available via the UI.
The backend component of the Deployment Automation server consists of a database, which is used to store system configuration, security, and process information. Physical artifacts, including the objects to be deployed to target locations and log files, are stored in a "Deployment Repository," which uses physically or logically attached disk or network storage.
An agent is an unobtrusive and secure process that runs on each target host and communicates with the Deployment Automation server. Agents are integral to Deployment Automation's client/server architecture. They deploy components and relieve the server from that task, making large deployments involving thousands of targets possible.
Agent Relays act as proxies and brokers, allowing the consolidation of traffic from many agents to route through a single point on the way to the business logic tier. Relays allow simplified firewall configuration and reduce the direct network traffic and processing load on the business logic tier.
Deployment Automation servers don’t actually perform "deployment work.” All deployment activities (moving files, adjusting configuration, starting and stopping, interacting with load balancers, and interacting with third-party tools) is undertaken by deployment agents
Agents run as a Java process, in the context of a JVM installed on a remote machine. They are low footprint, stateless, and subscribe to JMS requests provided by the Deployment Automation server. Agents are sent tasks by the server and run any appropriate commands using the plugin framework. Agents can also utilize web services provided by the server to get additional information or post back results.
