While UrbanCode Deploy may be installed on a laptop for learning purposes, the architecture is designed to scale to meet enterprise requirements: high availability, horizontal scalability, quick response, and tight security.


UrbanCode Deploy has four main components:

1. Service Tier:

The controller server or servers, sit in the controlling service tier. They provide the user interface, workflow engine, security service and more. Users log into them via web browser or command line to configure the tool, run deployments and view reports. These controllers have little state, if one fails another load balanced controller can take over seamlessly.

2. Data Tier:

Configuration for UrbanCode Deploy is stored in a back-end database (several database vendors are supported). Flat files, including deployable artifacts and logs, are stored in a storage system known as CodeStation which is typically backed by network storage.

3. Agents:

Work done on a remote target to help a deployment or import new versions is performed by Agents. Agents are small processes that do work on behalf of the controller servers.

4. Agent Relays:

Agent Relays are essentially proxies and agent brokers that consolidate traffic from many agents. They streamline firewall configuration and lessen the load on the controllers.


Controller servers with agents doing work

For performance and other reasons, the UrbanCode Deploy controller servers do not do deployment work. All deployment activities including moving files, adjusting configuration, starting and stopping, interacting with load balancers, and interacting with ALM and ITSM tools is performed by Agents.

Deploy with agents
An Agent is a light-weight, stateless, Java process running on a remote server. It subscribes to JMS topics provided by the controller server. When the controller puts out a task for it to run the Agent picks up the task, and runs the appropriate commands using the plugin framework detailed below. As necessary, it utilizes web services provided by the controllers to get additional information it needs or post back results.

Spans multiple data centers

Many organizations require deployments and availability across multiple data-centers. UrbanCode Deploy is architected to match the requirements of these organizations.

Agent Relay acting as a proxy
A common challenge with multiple data-centers is that firewalls exist between data centers or network segments. Enabling server-agent communication requires either broad firewall exceptions or many exceptions. The Agent Relay helps alleviate these challenges by consolidating Agent traffic. Relays may be installed in groups to provide high availability.
In the case of the loss of a data-center, being able to rapidly deploy applications can help in recovery efforts. In these situations, it is unacceptable to lose access to UrbanCode Deploy simply because it was installed in a data center that was lost. Therefore UrbanCode Deploy is designed to be installed across multiple data centers for redundancy and availability.  There are a variety of supported configurations and topologies. The image at left provides an example.


Plugins for integrations

The Plugin System evolved from the realization that much of the value of an automation engine comes from the integrations with other systems. Without integrations, an automation system can simply execute scripts and thus becomes a distributed scheduler. Worse, those scripts must be kept up to date on the all the target servers.

UrbanCode Deploy Agents do work by executing plugin steps. Many plugins are available today and clients are encouraged to build their own as well. The controller server sends the Agent instructions by telling it to run a plugin step, with information including:

  • The plugin to run
  • The name of the step from the plugin
  • The required version of the plugin
  • Parameters to pass to the plugin

If the Agent does not have the appropriate version of the plugin, it downloads it from the server. Then it runs the step with the appropriate parameters and processes the results while streaming log information back to the controller. This provides several advantages. Plugins may be added or upgraded independently of controller upgrades and are transparently delivered to the Agents that use them. All executed deployments log the version of the plugins used for audibility and repeatability purposes. If needed, old versions of plugins may be used in deployment processes as well.