Вы находитесь на странице: 1из 30

1. IBM Urbancode deploy uses agents and servers.

Agents runs scripts to

complete various actions. There can be multiple agents each one for every
environment or there can be a single agent.
2. ---- runs plugins (Agents)
3. Overview of usage of Urban deploy
a. Ensure that you have the agent running
b. Create a resource group
c. Create a resource for the given environment like testing, qa and bind
the resrouce to a physical agent
d. Create components (Web/Application/DB)
e. Create application and add components
f. Create environment and configure properties
g. Add resource to the created Environment and associate agent to the
h. Map components to the Agent
4. Resource is a logical deployment target and they are managed in a physical
or logical hierarchy called resource tree. The tree represents an agent, group
of agents, a component, an organizational hierarchy that is used to group
other resources.
5. What translates between agents and logical deployment targets for uDeploy
6. What combines resources into a single logical deployment targets environment
7. Resources on the IBM UrbanCode Deploy server represent the system
resources that are available to deploy
8. applications to, such as physical hardware or virtual machines
9. Component processes describe how to deploy, uninstall, update or run other
tasks on a component. For example component process for web component
can download the most recent version of the component artifacts and put
those artifacts in the correct folder.
10.Component contains file or configuration to be deployed and generally
mapped to something in an external system
11.Version contains the actual deployment of artifcats
12.Snapshot contains groups of component versions and configuration
versioning into one entity
13.There are three types of processes:
Generic processes run outside the context of components or applications.
Generic processes are shown on the top-level Processes tab.
Application processes run within the context of applications. In many
cases, application processes call component processes. For example, an
application process can call the component processes that deploy those
Component processes run tasks on a single component, such as deploying
it, uninstalling it, or running configuration tasks on it.
14.Applications are collections of components. Application is a logical group of
deployables and functions as a single unit. it self- contained defintions of
automation, target environment etc
15.Environments represent systems on which you deploy the application

16.Available plugins
a. Delete files and directories: deletes files in directories. Available under
utilities fileutils
b. Download Artifacts: downloads the latest version of artifacts. Available
under respositoreies artifact IBM Urbancode deploy
c. Move directory: copies or moves the content of directory. Used to
deploy content to the target deployment server. Available under
Utilities fileutils
d. Create .zip file creates zip file available under utilities fileutils
e. Start tom cat : starts the tomcat server. Available under Application
server Java Tomcat folder . needs the field launcher code to start
the server, timeout and port field
f. Unzip: extracts contents of compressed file like war file: availabnle
Utilities fileutils
g. Update property file: updates the property file with location of the
database. Available under - Utilities fileutils. Has three fields
Directory offset - the folder or the field name of the property; property
file name of the property file; add/update properties the exact
property value
h. Undeploy application: used to remove any older version of the
application in the server. Available under Application server Java
Tomcat . needs following fields
i. tomcat manager url
ii. user name and password
iii. context name like /TESTCONTEXT
i. deploy application deploys the application in server similar to
undeploy. But needs additional field war file path
j. Upgrade DB Updates the database. Available under database
DBUgrader. Requires fields
i. driverclass name like com.mysql.jdbc.Driver
ii. DB Driver Jar file lib/mysql-connector-java-5.1.10-bin.jar
iii. url
iv. user, password
v. SQL File path field (generally has a . )
vi. SQL File Include like *.xml
vii. Current Version SQL can specifcy specify the following SQL code: SELECT VER

viii. Delete Version SQL can specify specify the following SQL code: DELETE FROM

ix. Update Version SQL can specify specify the following SQL code: INSERT INTO

17.conditional flag in connections

a. By default, the conditional flag on each connection is set to success,
which is represented by a green check mark. The process follows these
connections when the step is complete.
b. The conditional flag fail is represented by a red dash (-). The process
follows these connections when the step fails.
c. The conditional flag both is represented by a gray circle. The process
follows these connections regardless of whether the step succeeds or

18.Examples of Variables values has to be defined separately. These are

environment properties that are included at the time of component creation
and included as parameters that specify various locations as given eblow and
defined as properties in the environment configuration:
a. ${p:environment/tomcat.home} Tomcat web server main folder
b. ${p:environment/db.url} database name
c. ${p:environment/tomcat.start}- start tom cat
d. ${p:environment/tomcat.port}
e. ${p:environment/tomcat.manager.url}
19.Create new component tab:
Accessed from Components menu Components tab create new

Source config type File system (Versioned)- declaring that each folder
under the 'Base Path' folder is actually a named version of the
component. Each of the versioned folders actually contains the files for
that version.

20.Importing new version - Components app name Versions Import

new version

21.Component Process is a script for deploying or managing the deployment of a

22.When a Process is executed, it runs on the target computer. It runs within a working
directory, which is defined by the DefaultWorkingDirectoryfrom the definition
of the Process. You can add a step to the Process to clean up the working directory by
deleting any content that it may already have. To do that, find Scripting>Shell>
Shellin the list of Available Plugins and drag and drop the Shellplugin into the

23.uDeploy remembers what version of a component has been deployed to a Resource.

Normally, if you run an Application Process that is deploying a component, if the
component version is already deployed, uDeploy doesn't redeploy the component.
However, if you turn the OnlyChangedVersioncheckbox off, then the component is
deployed even if the same version has already been deployed. This is very useful when
you are initially testing new Process scripts. Specifically, it lets you repeatedly deploy the
same application components

24.Snapshot - A snapshot is a collection of specific component versions and processes,

usually versions that are known to work together. Typically, a snapshot is created when a
successful deployment has been run in an uncontrolled environment. Snapshots can be
created in controlled environments as well. As the application moves components
through various environments, uDeploy ensures that the exact versions and processes
you selected are used in every environment. Snapshots help manage complex
deployments--deployments with multiple environments and development teams.
25.In general, avoid incremental deployments. While incremental deployments
can make sense for manual deployments, tracking incremental versions can
quickly become a nightmare with automated deployments. If you are
deploying 100 files, for example, deploy all of them every time and let
uDeploy figure out which ones have actually changed. This way, if a file was
unexpectedly changed, the deployment process itself will fix it.
26.What feature is common between Urban Deploy and release
Enforce quality gates for environment
27.What two features enables compliance in Urban code deploy
Audit History and Quality gates

28.Which screen shows the compliance i.e whether machine has the right
29.Exporting components creates a JSON
30.What is component template upgrade type

If the imported component was originally created from a template, use the Component Template
Upgrade Type drop-down box to specify how you want to use the template. For these options, the
template must be on the importing server. If the imported component was not created from a template,
these options are ignored

To use the imported component's template, select Use Existing Template. The new component will
be an exact copy of the imported one and contain a pointer to the imported component's template.
This option is especially useful if you are importing a lot of components based on the same template.
If you are upgrading, the component will also point to the imported template.

31.Component properties There are three types of component properties

Custom property, environment and version
32.Custom property cannot be modified if inherited from templates. Used in
scripts and plugins
33.Environment property - Available to environments that use the component.
The property will appear on the environment's Component Mappings pane
34.Component version - Each time a component's artifacts are imported into the
repository, including the first time, it is versioned. Versions can be assigned
automatically by uDeploy, applied manually, or come from a build server.
Every time a component's artifacts are modified and reimported, a new
version of the component is created. So a component might have several
versions in CodeStation and each version will be unique. A version can be full
or incremental. A full version contains all component artifacts; an incremental
version only contains artifacts modified since the previous version was

35. Inactive component versions remain in the repository (unlike deleted versions) but cannot be deployed.
To render a component version inactive, use the Inactivate action for the version (Components>
[selectedcomponent]>Versions>[selectedversion]>Inactivate). To make an
inactive version active, use the Show Inactive Versions check box and the Activate action

36. 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 created
with uDeploy's process editor

37. rocess type

Deployment: deploys a component version to the target resource and updates the inventory after a
successful execution.

Configuration Deployment: configuration-only deployment with no component version or artifacts

simply applies the configuration (using properties, or configuration templates) to the target agent and
updates the resource configuration inventory afterwards.
Uninstall: standard uninstall that removes a component version from a target resource and the
resource's inventory.
Operational (With Version): operational process which does not add or remove any artifacts or
configuration; runs arbitrary steps given a component version. Useful when you want to start or stop
some service for a previously deployed component version.
Operational (No Version Needed): same as the previous type, but does not require a component

38.Inventory Status - Status applied to component versions after being

successfully executed by this process. Active indicates the component
version is deployed to its target resource; Staged means the component
version is in a pre-deployment location. The status appears on the Inventory
panes for the component itself and environments that ran the process.

39.Default working directory - Defines the location used by the agent running
the process (for temporary files, etc.). The default value resolves to
agent_directory\work\component_name_directory. The default properties
work for most components; you might need to change it if a component
process cannot be run at the agent's location. Required
40.Required component role restricts who can run the process.
41.Component processes are typically run from within application processes but
can also be run by generic processes (Generic Processes) or other component
42.A component manual task is a mechanism used to interrupt a component
process until some manual intervention is performed. A task-interrupted
process will remain suspended until the targeted user or users respond
43.Three types of roles in component manual task - component, environment
and resource roles
44.Post processing - When a plug-in step finishes processing, its default postprocessing element is executed. The postprocessing element is defined in the
plug-in's XML definition, see the section called Creating Plug-ins You can
override the default behavior by entering your own script into the step's Post
Processing Script field. A post-processing script can contain any valid
JavaScript code. Although not required, it's recommended that scripts be
wrapped in a CDATA element.
45.Component templates - There are two types of templates available:
A component template enables you save and reuse component processes
and properties and create new components from them; template-based
components inherit the template's properties and process.
A configuration template is typically used to save server or property
46.A role property can be access by {P:resource/<<rolename>>/<<property
47.You can install an agent onto a Unix machine using the web application. A
remotely installed agent cannot be installed as a service
48.New agent is created under the menu Home resources agents
49.Managing agents - While we characterize an agent as a process (singular),
technically an agent consists of two processes: a worker process and a
monitor process. Worker processes perform the actual work of deployment,
such as handling plug-in steps. Monitor processes manage the worker
process: handling restarts, upgrades, and tests for example. Once an agent is
installed, you can manage (via the monitor process) many of it features from

the uDeploy web application. Agent properties can be changed directly by

editing the agent's conf/ agent/installed.properties file and restarting the
50.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.).
51.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

52.An Environment is a collection of Resources that host the Application.

Environments typically include host machines and uDeploy 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; uDeploy 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. uDeploy compensates for
these differences with Resource Groups (more at Resources by keeping an
Inventory of everything that is deployed to each Environment: uDeploy knows
exactly the Environment and Server(s) where the Application was deployed
to: and tracks the differences between the Environments
53.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, uDeploy 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, uDeploy 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

54.Notification scheme property in create application: Notification Scheme.

uDeploy includes integrations with LDAP and e-mail servers that enable it to
send out notifications based on events. For example, the default notification
scheme will send out an e-mail when an application deployment fails or
succeeds. Notifications also play a role in approving deployments: uDeploy
can be configured to send out an e-mail to either a single individual or to a
group or people (based on their security role) notifying them that they need
to approve a requested deployment.
55.Property enforce complete snapshot is present in create new application
dialog and enforces that every component of application is versioned
56.How can an application be upgraded through import
57.Can import application import components properties and processes yes
58.While importing application, if upgrade application checkbox is checked, then
application is upgraded else a new application is created
59.Application import component upgrade type drop down
a. Use existing component same components used by the imported
application is used. The new application will contain references to the
imported applications components. This option is especially useful if
you are importing a lot of applications. If you are upgrading, the
application will use the imported components, and no longer use any
not used by the imported application
b. Create new component - To create new components based on those
used by the imported application, select Create New Component. New
components will be created (based on the imported application's
components). If you are upgrading, the application will use the newly
created components and no longer use any it previously used
c. Failif component exists used for creating fresh installation. If you are
creating an application, it will create both a new application and
component unless the component already exists, in which case the
application is not imported. If you are upgrading, the upgrade will fail if
any imported components already exist on the importing server.
d. Failif compoenent does not exists - To ensure a component is on the
importing server, select Fail if Component Does Not Exist. If you are
creating an application, it will create both a new application and
component unless the component does not exist, in which case the
application is not imported. If you are upgrading, the upgrade will fail if
an imported component does not already exist on the importing server.
e. Upgrade if exists used to upgrade existing components. To upgrade
existing components, select Upgrade if Exists. This option creates an
application and upgrades existing components with data from the
imported application. If you are upgrading and existing components
match imported ones (all must match), the components will be
upgraded. If none of the imported components match existing ones,
the imported components will be used.

60.A resource is a deployment target, such as a database or J2EE container

61.Before you can run a deployment, you must define at least one environment
that associates components with an agent on the target host. This initial
environment is typically uncontrolled and often used to create snapshots.
62.Lock Snapshots check box property in create environment - If the Lock
Snapshots check box is selected, snapshots added to this environment will be
locked (forthe selected environment) to prevent changes
63.To ensure that components cannot be deployed to the environment without
first being approved, click the Require Approvals check box. If checked,
uDeploy will enforce an approval process before the deployment can be
deployed to the environment. Initial deployments are typically done in
uncontrolled environments, but once the deployment is successful, you can
configure an approvals process as the application moves along the
development pipeline. If you are setting up more than one environment,
consider creating an approvals process for at least one of them
64.Inherit cleanup settings in create new application - The Inherit Cleanup
Settings check box determines how many component versions are kept in
CodeStation, and how long they are kept. If checked, the application will use
the values specified on the System Settings pane. If unchecked, the Days to
Keep Versions (initially set to -1, keep indefinitely) and Number of Versions to
Keep (initially set to -1, keep all) fields are displayed, which enable you to
define custom values. The default value is checked.
65.A value set on component environment overrides one with the same name
set directly on an environment property. Component environment properties
enable you to centralize properties, tracking type and default values, for
instance. Environment properties provide ad-hoc lists of property=value
pairs. Referenced: ${p:environment/propertyName}.
66.Application processes, like component processes, are created with the
process editor
67.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.
68.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
69.An application process is always associated with a target environment. When
an application process executes, it interacts with a specific environment
70.Application processes are environment agnostic; processes can be designed
independently of any particular environment
71.Inventory management create new application process - If you want to
handle inventory manually, select Advanced. To have inventory handled
automatically, leave the default value, Automatic, selected
72.Offline agent handling is present in the create new application process
dialog. It Specify how the process reacts if expected agents are offline:
a. Check Before Execution: checks to see if expected agents are on line
before running the process. If agents are off line, the process will not
b. Use All Available; Report Failure: process will run as long as atleast one
agent defined in the environment is on line; reports any failed

deployments due to off line agents. Useful for rollbacks or

configuration deployments.
c. Always Report Success: process will run as long as atleast one agent
defined in the environment is on line; reports successful deployments.
73.Unlike approvals, manual tasks can be incorporated within an application
74.Process steps
a. Install component installs components and processes (can be
i. Use Versions Without Status - Restricts the components that can
be used by the stepcomponents with the selected status are
ignored. Available statuses: Active means ignore components
currently deployed; Staged means ignore components currently
in pre-deployment locations.
ii. Run on First Online Resource Only - Instead of being run by all
agents mapped to the application, the step will only be run by
the first online agent identified by uDeploy. The mechanism used
to identify the "first" agent is database-dependent (thus
b. Uninstall components uninstalls components and processes similar
to install component
c. Rollback components - Rolls-back a component version; replaces a
component version with an earlier one.
d. Manual application task - A manual task is a mechanism used to
interrupt an application process until some manual intervention is
performed. A task-interrupted process will remain suspended until the
targeted user or users respond. Typically, manual tasks are removed
after the process has been tested or automated.
e. Approval process - An approval process enables you to define the job
that needs approved and the role of the approver. An approval process
must be created if the Requires Approval check box is selected when
creating/editing an environment. If a scheduled deployment requiring
approval reaches its start time without approval given, the process will
not run and act as a rejected request. To resubmit a request, you must
request a new process. If an approval-requesting process does not
have a scheduled deployment time, the process will remain idle until a
response has been made.

Work items - If a job requiring approval is created, an approval process

will have to be created. The job requiring approval will display in the
approvers Work Items tab. Until approved, the job will remain idle if
unscheduled. If time has elapsed on a scheduled job needing approval,
the job will fail. This control allows the approver to verify the
deployment details, and choose the time it is deployed. Notifications
are sent to users who are eligible to complete an approval step if the
system is configured with an email server and the user has an email
address set
75.List of available manual tasks are
a. ApplicationDeploymentFailure
b. ApprovalCreated

c. TaskCreated
d. ProcessRequestStarted
e. DeploymentReadied
f. ApplicationDeploymentSuccess
g. Approval Failed
76.Create Snapshots:
a. Process Version locking field
i. Always use Latest Version Use the most recently defined
component process version for each component in the
application (default).
ii. Lock to Current Versions Use the current component process
version for each component.
b. For each of the component
i. Add Version Enables you to select any version in Codestation for
the component.
ii. Copy From Environment Uses the currently deployed (in this
environment) component version.
iii. Remove All Removes all deployed component versions from
this environment
c. Instead of specifying a version for each component, you can use the
most recently deployed version (in this environment) for each
component in the application by using the Copy All From Environment
d. If you want to discard any selected component versions, use the Clear
All Components button.
77.Approval behavior will differ based on schedule deployments and nonscheduled deployments. If a process with an approval does not have a
scheduled deployment time, the process remains idle until a response is
made. When a scheduled deployment that requires approval reaches its start
time and the approval is not given, the process does not run and acts as a
rejected request
78.UrbanCode Deploy has four main components:
a. 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
b. 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.
c. 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.
d. 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.
79.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.
80.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.
81.he blueprint designer accelerates application testing and deployment by
provisioning cloud environments and deploying application components to
those environments. You can put together a pipeline consisting of short-term
sandbox, test, and continuous-integration environments to long-term
production environments. Each blueprint models a full-stack environment,
including infrastructure layer and application layer.
82.The blueprint designer uses the OpenStack Heat Orchestration Template
(HOT) format to define environments. The web-based text editor shows that
native text format. The editor itself is based on Eclipse Orion, making it a full
featured editor in the browser. Syntax highlighting, error flagging,
find/replace and other core editor tools are all at your fingertips with standard
keyboard shortcuts
83.Agent can be installed either through script or through resources agent
install new agent button
84.Agent relay is installed in data center
85.Agents are installed in each deployment target
86.Replace with last deployed rollback option rolls back a failed deployment
automatically by catching the error in a process and automatically redeploy
the versions from before the process ran and thus reducing the downtime.
87.---- realm is used to determine a users identity within an realm for
LDAP, SSO or AD (Authentication, authorization)
88.---- realm manages the users and determine user identity within ---- realm
(authorization, authentication)
89.Pre requisites for setting up approvals for security
a. Application has notification schema selected
b. Users are added to the correct role
90.Where can you see the status of approvals - in reports Deployment
deployment details
91.What enables you to setup an environment quickly blue print
92.A component need to be added in
a. Application
b. Environment
93.Does the definition of resource include agent (Yes)
94.Environment within an application can have different
a. Topologies
b. Configurations
c. Settings
95.New environment can be created from Application tab/Environment tab
(Application tab. There is no tab called environment)
96.When do you need to add resources to Environment manually. When there is
no blueprint
97.Application process looks just like a component process but these steps are
not from plug-ins. Steps for applications are hard coded into Udeploy. Process

moves to the next step only if previous step was successful. If the component
process fails, then the application stops. You cant test the component
processes run right until you have the application process.
98.Various steps in step pallet of application process:
a. Install component choose a component deployment process to run
b. Install multiple components
c. Uninstall components remove all component versions from the
d. Roll back component switch between different incremental
component versions
e. Run process for each version runs a component process for each
component version
f. Run process for each affected resource runs a generic process on
each resource that is affected in the application process
g. Apply configuration runs an operational (non-version) or config
deployment process
99.Operational processes are processes in which components do not require a
Tags are set on ------- for an/a ----- (resources/environment)
What is used for load balancing (Tags)
Limit to tag option in properties window in component step limit the
deployment of component to specific resource tag
Security mechanisms
a. Roles and permissions
b. Approvals tasks
c. Status gates
Environmental approval is setup using two step process
a. First enable approval in the environment by selecting require approval
checkbox in Basic setting under applications app name
Environments configuration
b. Second define the approval from Applications app name
environments approval process and choose from either
application/environment/component approval task
Status gates are created in two steps
a. First define the status gates from main menu settings statuses
version status add status button
b. Add the status gate from applications app name configuration
environment gates and select the statuses
Application notification is set under application app name
configuration basic setting notification scheme
Environment gates setting is available under configuration menu. Is it
available under app name environment configuration or app name
configuration (app name configuration)
Menus available in main menu
a. Dashboard
b. Components
c. Applications
d. Configuration
e. Processes
f. Resources


Work items
Note that there is no environment in main menu


Menus available under selected application

Menus available under application Environment environment

a. Resources
b. Hisotry
c. Calendar
d. Configuration
e. Approval process
f. Changes
Snapshots help in audit, automation and visibility
User defined set of resources that host an application.
Environments have different topologies
Environments are assigned to specific applications
Approvals are assigned to specific environments
Server output is written to the
server_install_directory/var/log/deployserver.out log file. you can open the
file directly or access it from the UI (Settings > System > Output Log).
Resource groups can be of two types:
a. Static groups (the default type)
b. Dynamic groups
When you create the group, select Manage Members Automatically
to create a dynamic group that will be populated by using a naming
convention or property lookup.
Agent pool resources are used infrequently. When a step must run, but
the location doesnt matter, use an agent pool to distribute the load for
things like API calls.
Component resources can only be added to agent resources or child
agent resources.
Group of agents is an agent pool distributes the workload. Whichever
one is available you can use.
Whats the difference between a resource and an environment? the
resources are for a higher level of abstraction.

Resources dont do anything unless you have an agent and a
component. Agents define where it is being done and the component
resource defines what to do.
You attach a resource to an environment.
Resources have properties and tags.
Resources can contain other resources in a hierarchical tree structure
______ communicate with the Urban code deploy server to receive file
transfers and initiate operations on local computers to install application and
its pieces (Agents)
An agent must be installed on each operating system upon which local
commands need to be invoked as part of the deployment. Agents can serve
as proxies by making remote calls to machines thats an agent on a relay
server. Relay server communicates to agents on different hosts. Many plugins
use protocols such as REST, JDBC, and SOAP to deploy to target hosts where
agents are not installed.
the agent connects over Java message service (JMS) and subscribes
to a topic. Over JMS, the server instructs the agent to run a plug-in step and
provides a URL for HTTP connectivity. The agent downloads the required plugin, runs the step, and then sends execution output back to the server over
Below are
a. WebSphere Cluster
b. IIS Application Pool
c. Oracle DB Schema
Examples of
Below are examples of
a. Destination directories
b. Credentials
c. API endpoints
d. JDBC connection strings
Resource Properties/resources
( resource properties)

Ad-hoc resource properties can be accessed on ..

Configuration tab of the resource

Tags are applies to . (resources)
To ensure that availability of servers is taken care and not all servers
are taken offline, UDC provides tags When you orchestrate processes, you
might want to run automation in phases. To do run in phases, you can use
resource tags. By tagging primary servers as Primary, you have the ability
to limit application process steps to run only on primary servers. Tags can be
used to model a blue-green or A-B deployment.
What are the three type of resources
a. Agents
b. Resource Group
c. Component
A resource template is a model for a group of resources. The template,
which is a starting point for creating new resources, contains a hierarchy of
resources, groups, and agent prototypes.
Resource templates contain agent prototypes, which represent agents
that are not yet installed or connected to an environment. When you create
an environment, you can use a resource template as a model for the
environment. Then you can map real agents to the agent prototypes in the
Resource templates provide a pattern for an environment. For
example, you can use resource templates to represent dynamic cloud
The main features that make up a component are as follows:

Source configuration

Component versions

Component properties

Component processes
there are two flavors of plugins -the source config plugin or the
automation plugin.
Component Type: You can select one of two types of components,
Standard and z/OS. Choose z/OS only if this component is intended to be
deployed to a mainframe.
The Source Config Type is a way of specifying where you get artifacts.
When artifacts are imported automatically, IBM UrbanCode Deploy
periodically checks the artifacts for changes. Whenever changes are
detected, a new component version is created. You can control how often
artifacts are checked. You can import artifacts manually or have UrbanCode

Deploy import them automatically. The source can be DB tablesnot every

artifact is a file.
Two version types are available: full and incremental. Choose Full, if
the contents of the component versions represent the entire component.
Choose Incremental, if the contents are a subset of the full component. For
this course you select Full versions.
There are two types of versions Full and Incremental. With an
incremental version the agent compares the incremental version to the
inventory and deploys only the changed artifacts. It's not practical to
redeploy entire databases, for instance Incrementals are used a lot with
databases because you do not want to change the whole database. You do
not want to replace a whole database every time you have a change.
Incrementals are often the ones that are rolled back
What are the three options in import version setting while creating a

Inherit Cleanup Settings: Select this check box to inherit the
cleanup settings that are defined for the server. If not, you must define your
own cleanup policies. You usually check the inherit clean up box. That is to
use the default behavior. This has to do with how long versions are kept in
codestation. You can change the length of time the versions stay in
codestation in the system settings. The default is forever. If you have lots of
versions that is probably not what you want to do. By default it keeps every
version forever.
Component process - There are different types of component
processes, deployment is the most commonly used. Uninstall takes a
component off a resource. It leaves the component but it takes it off a
resource. Operational - does not change actual inventory but changes
properties. An operational process does not add anything new to the
environment. Operational could do something to the environment like start a
Process type - After you import a version, you define the process type
that deploys it. The idea is to create a repeatable process that can be reused
as new versions of the component are developed.
Inventory status - You can make your own statuses you could have a
complicated deployment that goes through different stages in which case you
could create your own statuses and direct UCD to use the different statuses
but by default there is only one active
The Default Working Directory: This value is the location from
which the agent runs the process on the target computer. By default, you see
this entry:${p:resource/work.dir}/${p:component.name}

Component process - The red circle indicates the direction to go if
the previous step fails. The gray circle indicates that you want the process to
follow a specific path regardless of whether the step passes or fails.
Component templates allow you to reuse component processes on a
different component or you could define the properties for any component
you create. It could include the component processes or it could not.

Deployment is the process of completing these actions:

a. Selecting component versions from a repository.
b. Moving those components to one or more targets, such as a web
c. Completing the required tasks for bringing those pieces of the
application online.
d. For example, a deployment might remove the previous version from an
application server, install a new version, and then start the new




UrbanCode Deploy server

The main server provides a web interface for administration and user
The server manages authentication and authorization for users (LDAP
integration is available too).
The server orchestrates integrations with other elements: agents,
other IBM software, or third-party software.

Are installed on each deployment target.
Communicate with the UrbanCode Deploy Server to receive file
transfers and initiate operations on local computers to install and
initiate the application pieces.
Local operations are accomplished with plug-ins.
Agents include Groovy libraries for running plug-ins, but plug-ins
can be written in any language or format that provides execution
capability on the local computer.
Main menu


Basic workflow
Create a base resource.
Add an agent to your base resource.
Create a component.
Add versions to your components.
Add component processes to your components.
Create an application.
Add components to your application.
Create application processes.
Create application environments.
Add a base resource to the application environment.
Add to the agents in resource tree component resources for each
component that is used in your application
In the application environment click Run Process

Light-weight processes that are installed on every deployment target
Provide two-way communication with the UrbanCode server
Stateless (resilient to network outages)
Can be secured by using SSL
Built on Java (requires JVM 1.7 or later)
IBM UrbanCode Deploy provides two types of plugins to define
deployment processes, with one type being referred to as Source
Configuration plugins. What is the other plugin type?
What is the difference between an application process and a
component process?
A. An application process coordinates component processes, while a
component process models automation of artifact deployment using

plugin steps

What can a snapshot capture?

Versions of components, processes, and properties


Which statement is true about a locked snapshot?

a. A. It allows you to avoid picking up latest untested changes at
deployment time.
b. B. It cannot be changed.
c. C. It is meant to lock certain users out of deploying a certain
d. D. It is not supported by IBM UrbanCode Deploy

At a high level, the security system in UCD consists of an
authentication realm, authorization realm, roles, and teams.
Authentication : This deals with user credentials , things like Can the
user log ? Does LDAP directory know this user, Has this user given valid
password ?It basically addresses the part Who you are
Authorization : Now that user has logged in , what the user actually
sees and can do in system is dealt here .
Role : Roles are all about levels of access , Roles do not know
anything about user or teams . For example A developer-type role might
have permissions that enable it to create applications but not run them in
production environments, while a deploy-type role might be able to run
applications but not create them.
Team : Teams provide two important functions. First, a team provides
the mechanism to assign users roles. When a user is assigned a role, all
permissions that are granted to the role are automatically granted to the
user. Second, teams secure product resources. When a team is attached to a
resource, only team members with the appropriate permissions can interact
with the affected resource.
Resource properties will not resolve in the application process scope as the
application process does not run against any specific resource. You'll have to reference the
property in the component process in order to have it resolve correctly

The component resource type is used to further fine tune access to your component
based on the team mapping. You can configure different permissions for your roles based on
what resource type you have defined. This is only visible from you component when you add
a team to your component. You would then have to select a different component resource
type from the standard component resource type.


The core installation of IBM UrbanCode Deploy includes a server, agents, and a
license server. Clients access the server through web browsers, the REST API, or the
command-line client. Agents can be installed on cloud environments, virtual machines
(VMs), containers, or physical systems; the agents are shown on cloud systems in the
following diagrams, but they can be installed on many different systems

Most agent communication is via JMS (bi-directional). Some
activities use HTTP, however (one-directional from agent to server):
Posting logs
Transmitting test results
Posting files to CodeStation
In simple configurations, agents communicate directly with the
UrbanCode server.
In more complex situations, direct communication becomes inefficient
or impossible:
The number of agents increase from tens to hundreds to thousands.
Network topology becomes complex.
Agent-server communication crosses firewalls with port restrictions.
Agent relay servers resolve this issue.

The Relay server:

Also known as Agent Relay.
A server that is used to relay commands from the main UrbanCode
server to the agents.
Used to cross firewalls, where communication to multiple machines
and ports is restricted.
An agent doesnt have instructions to do anything. The instructions
come in the form of a plug-in. To run a shell command, there is a shell
plug-in. Many WebSphere plug-ins are available.



The worker is as follows:

A service that is a multi-threaded process
A service that performs the actual deployment work on the target
The monitor is as follows:
A service that manages the worker process: starting and stopping the
A service handles restarts, upgrades, and security
Work commands come from plug-in steps, which provide integration
with many third-party tools.
After an agent is installed, it can be managed from the UrbanCode
Deploy web application.
Security for server and agent communication
By default, UrbanCode Deploy uses these security measures:

Secure Socket Layer (SSL) in unauthenticated mode for JMS-based

server/agent communication. Communication is encrypted and
decrypted, but agents do not have to authenticate with the server.
Unsecured HTTP for agent-to-server messages as described earlier.
HTTP communication can be secured with SSL:
At installation time
After installation through configuration changes

Stateless server-agent communication
Significant benefits to performance, security, availability, and disaster
recovery are provided.
A transaction consists of an independent message.
The message can be synchronized to secondary storage as it is sent.
This synchronization results in resilience to network outages. Either
endpoint, server or agent, can be taken down and brought back up
without repercussion (other than lost time).
If communications fail midtransaction, these actions occur upon
The server and agent automatically determine which messages got through
and what work was completed.
The system synchronizes the endpoints and recovers affected processes.
The agent communicates the results of work that an agent performed to the
Develop and test against a production-like system
Iterative and frequent deployments using repeatable and reliable processes
Continuously monitor and validate operational quality characteristics
Amplify feedback loops
Commit stage compile, commit tests, assemble, code analysis
Acceptance stage configure environment, deploy binaries, smoke test,
acceptance test
Uat stage /capacity stage/production stage - configure environment, deploy
binaries, smoke test. In addition to this capacity stage has run capacity test
Typical deployment
Content Deployments
Incremental content updates
Middleware Code Deployments
Install and rollback of code
Run-book automation (restart, etc.)
Middleware Configuration Deployments
Declarative description of configuration change
Install and rollback of config change
DB Deployments
Execution of DB change scripts in order


Coordinates component level processes
Same processes used across environments



- Translates between agents (actual execution) and logicl deployment
targets for uDeploy
- Can point to another resource, agent, or pool, but it
must be able to resolve to an agent somehow
- Best place to put target-specific configuration

UrbanCode improves software delivery enabling continuous release
and deployment via application release automation, helping to drive down
costs, speed time to market and reduce risk.
Deployment Automation Developer or Deploy Administrator imports
the AMC Plug-in into Deploy. The Plug-in is configured to auto-discover WAS
installs on specific resources so when the agent comes on-line it will invoke
the AMC plug-in which will discover the cell topology and create WAS Cell and
WAS Cluster subresources back on the Deploy server.
A Middleware Administrator or Application Developer unzips the AMC
plug-in on a system that has connectivity to the exemplar WAS cell
The Middleware Administrator or Application Developer will run a script
packaged in the AMC plug-in that will prompt for some information, then
discover and import configuration from the exemplar WAS cell
The AMC template creation script will ask the user for a base product
template (e.g. WAS v8.5) and to chose what configuration data from the
imported cell should be added (either only cell scoped configuration or a
cluster configuration). Note that if any custom tokens are required (e.g. host
specific information like JDBC connection URL, etc.), then the Middleware
Administrator or Application Developer will need to open the appropriate
template file up for editing and insert the tokens manually. They will then
need to create appropriate properties on the appropriate WAS Cell/Cluster
resources to ensure the token substitution happens correctly during
deployment (this is not directly shown in the diagram above for the sake of
The AMC template creation script will prompt the user for information
required to connect to a Deploy server, including the name of the WAS
configuration component and will create/update the template in CodeStation.
The Deployment Automation Developer should now have all the Deploy
artifacts he needs to assemble the Application including deploy/undeploy
The application, including WAS configuration, can be deployed and
promoted across all environments defined in the application

In networking terms, agents establish long-lived JMS connections with
the relay (default port 7916) and the relay establishes long-lived JMS
connections with the central server (default port 7918). The server
communicates back over these persistent connections to issue instructions to
the agents. Agents can be instructed to interact with the server via web
services, which take place on HTTP/S (default ports 8080 for HTTP, and 8443
for HTTPS). For agent-agent relay HTTP/S communications the default port is

Source Config. Setup

When creating a new component, you will need to identify where
uDeploy will pull the artifacts. This is done by selecting one of the
options in the Source Config Type. Once that is identified, other fields
will appear based on what you selected.
Define the source type and identify the artifacts associated with the
The source type can be any, or nearly any, associated with a software
Once defined, all artifacts must be of the defined type.

Component Version Import
Manually Importing Component Versions
To import a new component version manually, you will need click
Import New Version and specify the source location of the content you
will deploy. The source location of the new version will have to be
different from the original location of version 1. If the source location is
in a version repository, you can point to the repository and uDeploy will
pull the new version from it.
Automatically Importing Component Versions
To import a new version automatically, we will edit the component, and
check Import Versions Automatically, see Screen 3. When checked,
uDeploy will periodically poll the version source on the uDeploy server.
The user specifies the polling time in uDeploys System Settings.
uDeploy recommends that you not set the polling time below 15
seconds. When the polling time expires, uDeploy checks the source
repository for changes within the component. If any changes have
occurred, the component will automatically be imported and versioned
in uDeploy. If Copy to CodeStation is also selected, uDeploy will import
a copy of the new version into CodeStation.
uDeploy tracks all artifact changes which enables you to rollback components
or deploy multiple versions of the same one.
Component Template Properties- Ensures that every component
created from a template has the same properties

There are 3 types of available properties


Component Property Definiation

Environment Property


a. A step has access to properties set earlier by other steps within the
b. Properties set by the application that invoked the component process
as well as those on the Target environment and resource.
c. Step property values become unavailable once the component process
d. Every item from the table below will use this format, $
{p:version.name} ${p:enviornment/propname}
Order of Precedence:
Component Version

A subresource enables you to apply logical identifiers, or categories,
within any given Resource Group. During deployment configuration, you can
Select a given subresource that the Process will run on.

A security report provides information about user roles and privileges

Authentication Realms determine a users identity within an
Authorization Realm. Authentication is determined following the hierarchy of
When adding component versions, use the push method
wherever possible. Polling methods, such as a Nexus repository, strain both
uDeploy and the repository, which can lead to versions being missed or


Server log
a. You can download the uDeploy server log from within the web
b. To download the log file:
c. 1. Display the Output Log dialog by clicking the Output Log link on the
Settings pane.

d. 2. Click the Download Log button to save the file.

e. 3. Optionally, you can download the file directly from the Settings pane
by clicking the Download link on the Settings pane. The uDeploy server
log file is normally found in the following location: