Exploring the IBM UrbanCode Deploy 6.0.1 Plugin Changes

Plugins are a major piece of the value of the IBM UrbanCode Deploy tool.  They provide a simple way to automate adjacent pieces of the application’s environment in a way that allows you to move users away from direct access to deployment target environments. IBM UrbanCode  Deploy are pretty modular, easy to manage, easy to create, and provide a great way for either the product team or customers to extend the value of the tool. However, as the number of plugins grows, it becomes that much more important to track what is going on with them so that you can identify new integration opportunities and track potential improvements to ones you are already using.

With the advent of the 6.0.1 release, a number of plugins have been added and a number have changed.  Unfortunately, I have yet to see a comprehensive list of what plugins have been added or changed, so I did a little digging and compared the plugins that shipped with 6.0 and those that shipped with 6.0.1.  This initial pass is just a cursory look to see what’s there.

My approach was to do a binary comparison between all of the files even if they had the same name.  That enabled me to verify that the contents had not changed between releases.  It also enabled me to identify files, such as the Remedy plugin, that changed names between releases, but were unchanged at the content level.

If people are interested, I will dig into the next layer of seeing which of the updated plugins have substantive additions, such as new methods or properties, and which appear to just have fixes without obvious operational changes. Please consider this a standing invitation to add your findings in the comments.

Downloadable list: I created a handy PDF if you want to download the summary in a more consumable form.   Available here if you are interested:  IBM_UCD_60_to_601_plugin_comparison

In the meantime, I hope this list will help those upgrading to know what they need to look at and what they can ignore.

New (did not exist in 6.0 but do in 6.0.1)

  • AgentPropertiesCollector-2.455141.zip
  • AnthillSourceConfig-1.455112.zip
  • ClearCaseSourceConfig-1.455167.zip
  • FileSystemSourceConfig-1.455169.zip
  • FileSystemVersionedSourceConfig-1.455159.zip
  • GitSourceConfig-1.455161.zip
  • ibm-ucdeploy-publisher.hpi
  • MavenSourceConfig-1.455170.zip
  • plugin-air-RTC-WorkItems-2.455564.zip
  • RAMSourceConfig-1.455163.zip
  • SubversionSourceConfig-1.455152.zip
  • TFS-SourceConfig-1.455154.zip
  • TFS_SCM-SourceConfig-1.455162.zip
  • uBuildSourceConfig-1.455076.zip
  • web-utilities-1.446294.zip
  • WebSpherePortal-1.452361.zip
  • WindowsFailoverCluster-3.455119.zip

Updated (Changed between 6.0 and 6.0.1)

  • ApplicationDeploymentForWebSphere-68.455164.zip
  • Chef-1.455055.zip
  • FileUtils-31.455052.zip
  • GreenHat-1.455099.zip
  • ibm-ucd-agent-script-package.zip
  • JBoss-6.455062.zip
  • JUnit-1.455144.zip
  • Maven-2.455085.zip
  • MCWASPlugin-3.131121.zip
  • RPM-2.432456.zip
  • RQM-2.455153.zip
  • ServiceNow-8.450859.zip
  • Shell-3.455056.zip
  • SQLCmd-4.455081.zip
  • SQLPlus-6.455179.zip
  • SystemInformation-2.455048.zip
  • Tomcat-4.455075.zip
  • uBuild-4.455175.zip
  • uDeploy-Application-63.455151.zip
  • uDeploy-Component-61.455109.zip
  • uDeploy-Environment-64.455050.zip
  • uDeploy-Resource-64.455077.zip
  • uDeploy-System-61.453415.zip
  • uDeploy-Version-60.455054.zip
  • uDeployConfigManagement-3.455073.zip
  • UrbancodeVFS-18.455070.zip
  • Urbancode_Package_Manager-3.455115.zip
  • WebSphere Liberty-2.455142.zip
  • WindowsSystemTools-13.455110.zip

Removed (Were in 6.0 but not in 6.0.1)

  • Example.zip
  • WebSphereMessageBroker.zip

Unchanged (Showed no difference between 6.0 and 6.0.1 package)

  • Remedy-1.423633.zip   (*renamed, but unchanged)
  • air-worklight-1.423586.zip
  • AmazonEC2-4.423632.zip
  • Ant-2.423681.zip
  • Anthill-7.424532.zip
  • Apache-1.423580.zip
  • DBUpgrader-1.423703.zip
  • DeployTools-5.423702.zip
  • F5-8.423587.zip
  • Groovy-2.423689.zip
  • IIS-AdminScripts-7.424216.zip
  • IIS-AppCmd-2.423623.zip
  • IIS-MSDeploy-1.423639.zip
  • JIRA-3.423640.zip
  • LinuxSystemTools-8.423698.zip
  • Rally-1.0.0_b423612.zip
  • Selenium-3.423652.zip
  • ServiceControlManager-8.423610.zip
  • Sharepoint-4.423644.zip
  • SQL-JDBC-4.423630.zip
  • Subversion-export-2.423664.zip
  • WebSphereMQ-1.423574.zip
  • WebSphereMessageBroker-CMP-6.424588 (1).zip  (*renamed, but unchanged)

 

Advertisements
Tagged with: , , , , , , ,
Posted in DevOps, UrbanCode Deploy

IBM UrbanCode Products updated to 6.0.1

The 6.0.1 versions of IBM UrbanCode Deploy and IBM UrbanCode Release are available.   As the UC suite is still new within IBM’s portfolio and being brought into line with the rest of the products, these are more substantial “.0.1” releases than the version number increment implies.   Handily, Eric Minick has put a number of posts on the UrbanCode blog site tagged with “v6-0-1” that cover the improvements to both products nicely.

Clicking this URL will give you all the posts with that tag:  http://blogs.urbancode.com/tag/v6-0-1/

Tagged with: , , , ,
Posted in DevOps, Uncategorized, UrbanCode Deploy

IBM UrbanCode Deploy LDAP Howto

Integrating tools with LDAP all to frequently turns into a lengthy endeavor marked by misunderstanding and misinformation around something that should be a fundamentally simple exercise.   Some of this is due to common misunderstandings of how LDAP is set up in a particular environment and some is due to the varied ways in which tools consume data from LDAP directories.  This video focuses on the new IBM version of UrbanCode’s uDeploy tool – now called IBM UrbanCode Deploy- and how to connect it to an LDAP directory.  While not an LDAP tutorial, I tried to add some helpful tips / tricks that will may help someone with only a basic understanding of LDAP accomplish the integration without requiring the services of an LDAP guru.

Tagged with: , , , , , , , , ,
Posted in DevOps, HowTo, UrbanCode Deploy

Conditional Process Flows in IBM UrbanCode Deploy

The IBM UrbanCode Deploy tool has the ability to create robust, automated processes.  One of the fundamental techniques for improving the sophistication of these automated flows within the UrbanCode Deploy tool comes from the ability to use the outcome of a step in the flow to control which subsequent steps get run.  This video takes a look at this technique and should help novice users get a handle on how to begin using it to improve their process flows.

Tagged with: , , , , , , , , ,
Posted in DevOps, HowTo, UrbanCode Deploy

Plugin Example: 7zip

The plugin for 7zip is a very simple plugin that only contains one step. Looking at the snapshot, we can find the three main files: plugin.xml, upgrade.xml, and info.xml.

7zip file directory

The plugin.xml doesn’t look much different from what we have seen before.The header element with the identifier, description, and tag information all filled out.

7zipheaderxml

The step-type element is also filled out with the expected information. The properties section is filled with information that will be displayed under the process section when working with the individual plugin steps. Notice how each property in the plugin.xml file matches up with the properties in UCD.

7zipxmlproperties

Also, note how the information stored in the command elements. The attribute program is using an environment property. The path attribute is pointing to the jar files located in the lib directory.

7zipcommandxml

The extract.groovy is a script that finds the files the user has listed and confirms that they exist and reads them in. Below is a snippet fo the extract.groovy file. It is searcing for files to process. Groovy is syntactally simmilar to Java. For more information on Groovy, click here.

7zipgroovyexample

If you are trying to write a plugin for your organization and don’t know where to start I would suggest downloading any of the plugins from the UrbanCode website and examining the files that are contained inside of the zip file.

Posted in Uncategorized

Writing A Plugin

UCD (UrbanCode Deploy) is designed in such a way that any software that you currently use in your development lifecycle can be supported by writing a plugin. Writing a plugin for UCD is pretty straight forward but it can seem like there is a lot of magic and hand-waving happening. Once you understand the requirements and learn the nuances writing a plugin for UDC is pretty simple. Here is what you need to get started: working knowledge of JavaScript & Groovy, and three xml files (plugin, update, & info). Plugin.xml and update.xml are required files while info.xml is optional, it is used to describe the plugin and to provide release notes.

Example of Plugin.xml

<?xml version="1.0" encoding="UTF-8"?>
<plugin xmlns="http://www.UrbanCode.com/PluginXMLSchema_v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<header>
<identifier id="plugin_id" version="version_number" name="Plug-in Name" />
<description>Description goes here </description>
<tag>Plugin_type/Plugin_subtype/Plugin_name</tag>
</header>
<step-type name="Step_Name">
<description />
<properties>
<property name="property_name" required="true">
<property-ui type="" label="label" description="description goes here"
default-value="" />
</property>
</properties>
<post-processing>
<![CDATA[
if (properties.get("exitCode") != 0) {
properties.put("Status", "Failure");
}else {
properties.put("Status", "Success");
}
]]>
</post-processing>
<command program="${path_to_tool">
<arg value="parameters_passed_to_tool" />
<arg path="${p:jdbcJar}" />
<arg file="command_to_run" />
<arg file="${PLUGIN_INPUT_PROPS}" />
<arg file="${PLUGIN_OUTPUT_PROPS}" />
</command>
</step-type>
</plugin>

The <header> information is very basic and contains three additional elements.
<identifier> is information that is used to id the plugin you are writing within UCD as well on the UCD’s website if you submit the plugin.
<description> describes the plugin. The description information will be displayed under the settings section after loading the plugin into UCD.
<tag> is used to categorize the plugin against the other the plugins that are already installed.

The <step-type> is also pretty straight forward. <step-type> is a single action being taken. If you are creating a plugin that needs to create a file, write to the file, and move the file to a new location, you would have three <step-type> tags:

<step-type name=”Create File”>
<step-type name=”Write to File”>
<step-type name=”Move File”>

The <command> element is run before the <post-processing> element.  The individual steps are run by invoking a scripting tool that is defined within the command element. This is where the scripting language becomes important. You can use any scripting language you choose including JavaScript, Ruby, or Pearl but Groovy is supported natively.

Basically you are creating a JavaScript or Groovy file that will interacts with either an API or your program directly. The steps you are creating in the plugin.xml file are an intermediary between UCD and your program. In these steps you are telling UCD how to interact with your program.

The <post-processing> element is run after the <command> element and sets the output properties, provides error handling, and determines if the interaction between your plugin and UCD has completed successfully. This section must be written in JavaScript.

Example of Upgrade.xml

<?xml version="1.0" encoding="UTF-8"?>
<plugin-upgrade xmlns="http://www.&company;.com/UpgradeXMLSchema_v1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
</plugin-upgrade>

The upgrade.xml file is required but doesn’t have to be filled out. If this is your first version, then there wouldn’t be any upgrades. You can update this section with your information and leave it blank until there is a need to update your plugin.

Example of Info.xml

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<pluginInfo>
<!-- **author name IS required** -->
<author name="IBM">
<organization></organization>
<bio />
</author>
<!-- **intergration type IS Required** -->
<integration type="Automation" />
<!-- **source is NOT required** -->
<!-- <source url=""/> -->
<!-- **license type is NOT required** -->
<!-- <licenses> <license type=""/> </licenses> -->
<!-- **tool-description IS required** -->
<tool-description></tool-description>
<!-- **related-info is NOT required** -->
<!-- <related-info> <link title="" type="" description="" url =""/> </related-info> -->
<!-- **meta-html in NOT required** -->
<meta-html>
<meta content="" name="description" />
<meta content="" name="keywords" />
</meta-html>
<!-- Do not change the release-version, the build process injects it. -->
<release-version>0.0</release-version>
<release-notes>
<!-- **release-note IS required** -->
<release-note plugin-version="0.0">
</release-note>
</release-notes>
</pluginInfo>

Tagged with: , , , , , , , ,
Posted in Uncategorized

IBM UrbanCode Introduction

The UrbanCode Deploy application is doing away with manual deployments, giving the ability to automate deployments to hundreds of servers in multiple environments, and is changing the deployment paradigm. Software is now being pulled through the development pipeline with the click of a button instead of pushing it through. Some of the features that UrbanCode Deploy brings to the table include:

Snapshots
A snapshot is a group of components such as business logic, databases, and configurations. Each component maintains an independent version. Being able to select each version gives a greater level of control over the deployment. If the latest version of a component has a defect another version can be selected.

Automated Processes
Processes are at the component and application level. A process is a group of steps. A component can include a database, a server, an application, and static files in any combination. Each component is individually managed. A database could have specific steps defined to update tables or have them rolled back during a failed deployment. An application can have multiple environments defined such as development, testing, and production. A snapshot gets deployed to these environments. The processes that are defined in each component that are in the snapshot are run over and over when deploying. No more manual steps.

One Click Deployments
An application can now be deployed to any environment with the single click of a button. Once an environment is defined components are deployed to them. That’s not to say that a checks and balances system is missing. There is a security model in place that allows teams and managers to approve components before deployments.

Scheduled Deployments
Deployments can also be scheduled. Schedule a deployment once a day for the development team, once a week for the test team, and once a month to deliver the latest updates into production.

Failed Deployments
If a process fails and a component isn’t deployed a rollback feature is already built into the application. No more being stranded when deployments go wrong. If a failure happens there is a process already in place to undo the changes made by reverting back to a known working snapshot.

Extensible
The tool comes with about a hundred plugins for some of very well-known industry standard tools. If your tools aren’t supported or you have a home-brewed tool you can write a plugin to make UrbanCode Deploy work with your tools.

Tagged with: , , , , , ,
Posted in DevOps, UrbanCode Deploy
DevOps

Avnet Services DevOps Team Blog

BamBytes

Just another WordPress site

Crossing Silos

DevOps only works if you cross boundaries

Avnet Services DevOps

Avnet Services DevOps Team Blog