To see a working example of a blue-green Kubernetes deployment in UrbanCode Deploy, watch this video:.

For step-by-step instructions on how to setup the working example shown in the video, see this article.

This document explains how to set up UrbanCode Deploy to manage your Blue-Green and Canary Kunbernetes deployments in general terms.

Getting Started

In a blue-green deployment, two versions of your application may be deployed at the same time while traffic is being sent to only one of the deployments. For example, version 1.0 of your application may be running as your “blue” deployment, while version 2.0 is running as your “green” deployment. A load balancer may direct all users to the blue deployment (version 1.0). Once version 2.0 has been staged and verified, the load balancer may be changed to send users to the green deployment (version 2.0). This allows for zero downtime deployments.

In a simple Kubernetes blue-green deployment, you may have three YAML files. The first YAML file describes the load balancer. The load balancer has a selector which directs traffic to deployments containing either a blue label or a green label. You may also have a deployment YAML file containing the blue label, and a similar YAML file containing the green label.

Setting up the UCD Components

First, let’s create a component to represent our load balancer. In UrbanCode Deploy, go to Components and click the Create Component button. Enter a name for your component. In the Component Template field, choose the Kubernetes template. If you don’t see the Kubernetes component template, download and install it from Github. Save your component, keeping in mind that we will be creating component versions and component version artifacts (how you chose to do so is up to you).

Next, create two copies of your load balancer’s YAML file. In one file, set the selector to blue. In the other file, set the selector to green.

In your load balancer component, create a new version named green. Add the load balancer YAML file with the selector set to green as a component version artifact.

In your load balancer component, create a new version named blue. Add the load balancer YAML file with the selector set to blue as a component version artifact.

Your load balancer component should now have two versions: blue and green.

The load balancer component is complete.

Next, we will create a component that represents our application.

While blue-green deployments typically use separate files for the blue and green deployments, we will use the power of UrbanCode Deploy to simplify things and use a single file for the deployment. We can then change the versions of containers running in either the blue or green deployment using UrbanCode Deploy, freeing us from manually changing multiple YAML files. If you are unfamiliar with these features, see this article.

To use a single deployment YAML file, we will change the color value in a YAML file to a token. For example, a YAML file representing our blue deployment may look like this:

Create a component to represent our application’s YAML file. Use the Kubernetes component template when doing so. Create a component version with your YAML file as a component version artifact. You may follow the Enhance your Kubernetes Experience with UrbanCode Deploy article for more details.

Click the Next button. Select your Kubernetes and your Load Balancer components in their respective fields. Click the Next button.

The next page of the wizard shows environments to use in this application. By default, there are Blue, Green, and Load Balancer environments. Notice the Blue and Green environments include a property named Color. The Color property is set to blue in the Blue environment, and green in the Green environment.

Click the Blue environment’s Request Process button to deploy the blue version of your application. Choose the Deploy Application from YAML process and select the version of your application’s YAML file to use. Note: the first time you run this process, the versions of the containers will be set to whichever versions are specified in your YAML file. Going forward, you will have the ability to change container versions. Click Submit to start the Deployment process.

Click the Green environment’s Request Process button to deploy the green version of your application. Choose the Deploy Application from YAML process and select the version of your application’s YAML file to use and the desired version for the containers used in this environment. Click Submit to start the Deployment process.

Once complete, you may click the Expand All link on the Application page for your application and easily gather information regarding your deployment:

In this example, we see our Load Balancer has the blue version deployed, meaning traffic is being sent to the Blue environment. In our Blue environment, version 1.0 of our container is deployed, while version 2.0 has been deployed to the Green environment. Once version 2.0 of the container is thoroughly tested and we desire to send traffic to the Green environment, simply deploy the load balancer again choosing version green. To change the version of the application yaml or containers deployed in an environment, simply deploy new versions.

Canary Deployments

A similar approach may be taken for managing canary Kubernetes deployments using UrbanCode Deploy.

Review this blog post on the Kubernetes site, especially the section titled Multi-Stage Canary Deployments. Similar to the blue-green deployment example, the blog shows a cluster of HAProxy pods that are used as a load balancer. The cluster is set to send traffic to four different environments in the example (Internal, Canary (Free), Canary (Paid), Production). UrbanCode Deploy could manage the deployments as a build moves from Internal to Canary (Free) to Canary (Paid) to Production. Using the power of UrbanCode Deploy, users beneift from audit trials to show who deployed which containers and when they deployed them as well has providing governance over who is allowed to perform the deployments and to which environments.

One important part of setting up a high-availability cluster of IBM UrbanCode Deploy servers is making sure that the agents can connect to the servers. If you’ve got four servers, how does an agent know which server to connect to? Part of that task, of course, is getting your failover connections set up properly. Another part is getting cluster connections configured between the servers.

Cluster connections, formerly known as network relays, open a port for Java Message Service communication between servers. These connections allow the servers to accept incoming JMS connections from agents and route the agent communications to the appropriate server. That way, each agent connects to the server that is running workflows on that agent.

For a while I thought that every server had to have a cluster connection to every other server, but I was wrong. Because the servers share the connections, you need only one cluster connection to each server in the cluster, including the server on which you create the connections. So if I’ve got four servers, I go to Settings > Network on one of those servers and create entries for each server. Those four connections look like this:

Those four cluster connections create links from each server to each other server. Here’s what the topology looks like when that’s all set up. The diagram shows two agents that connect to a cluster of four servers. The four servers are connected by four (total) cluster connections, even though it looks like more connections than that on the diagram.

This is part of why you don’t need to (and shouldn’t) route the JMS connections (default ports 7918 and 7916) through a load balancer. The servers create a JMS mesh that shares this information between them. JMS connections are long lived and have state information that isn’t visible to load balancers, so in this case load balancers don’t work well with JMS, anyway. However, the HTTP traffic from agents and users to the servers should be routed through a load balancer.

Overview

Over the past couple of years, Jenkins has emerged as one of the most popular build tools. The Jenkins Pipeline, since version 2.0, provides a solid continuous integration approach for simple application test environments. Once users reach full-scale, production deployments, they begin to realize its limitations. While strong individually, Jenkins does not scale to coordinate and deploy multiple services and components. This fault is where IBM UrbanCode Deploy excels.

IBM UrbanCode Deploy enables users to develop a highly customized deployment strategy that can harmonize with any number of microservices and environments. In these scenarios, users can continually and confidentially deploy to different environments and quickly identify the root issue when a deployment fails. Furthermore, IBM UrbanCode Deploy provides a process record to remind the release team what deployments were successful, what sequence of processes were run, and the state of each environment and process. With this information, release managers can save configurations in the form of Snapshots and return to successful states when deployments or configurations go wrong.
In this blog, we will cover two scenarios to help you quickly get started with IBM UrbanCode Deploy and Jenkins Pipeline:

Build an artifact in Jenkins and push it into IBM UrbanCode Deploy as a Component Version

Deploy an IBM UrbanCode Deploy Snapshot from Jenkins

These two walkthroughs explain the most important features of the Jenkins Pipeline integration and how these ideas can be expanded upon further in future deployment scenarios.

The Jenkins Pipeline Plugin

The IBM UrbanCode Deploy Jenkins Pipeline plug-in enables the import of Jenkins build artifacts and can initiate IBM UrbanCode Deploy server’s deployments. The plug-in is installed on the Jenkins server and can be configured through Pipeline script syntax or form fields. The most common complete use case, which we outline in the below walkthroughs, has three basic steps:

The IBM UrbanCode Deploy Pipeline plug-in pushes the artifacts into IBM UrbanCode Deploy as a new component version. (Walkthrough #1)

Lastly, the Pipeline plug-in configures and triggers an application process in IBM UrbanCode Deploy using a component version or snapshot. (Walkthrough #2)

The Jenkins Pipeline plug-in is similar to other source configuration plug-ins as it moves artifacts from a source control or build server into IBM UrbanCode Deploy’s CodeStation. Once these artifacts are within CodeStation, Deploy can begin any defined deployment to your configured environments. However, because the Jenkins plug-ins are installed into the Jenkins server itself, not IBM UrbanCode Deploy, the import process relies on a push, rather than pull, model. By importing on a push basis, IBM UrbanCode Deploy agents are alleviated of extraneous work and wasted time when querying for new builds that do not exist. Most importantly, this approach allows for the immediate deployment following the artifact’s creation in the build server. This minimizes downtime and greatly increases the value of any continuous integration pipeline. We highly recommend a push approach when integrating with all build tools.

Summary: Component Version Import

The below walkthrough outlines the configuration of the Jenkins Pipeline plugin and a simple component import use case. This demo requires an IBM UrbanCode Deploy and Jenkins servers reachable on the same network. If you do not have a Deploy or Jenkins servers available, we have created a Docker Compose file that can build the servers in a few minutes. There are also a few scripts available that install the Jenkins plugins and generate generic Jenkins Jobs.

Integrating IBM UrbanCode Deploy and Jenkins with the Jenkins Pipeline plug-in is good first step towards a continuous integration pipeline. In this walkthrough, we will use Jenkins to build an open source plugin and push the compiled file into IBM UrbanCode Deploy as a component version. In the next walkthrough, we will then use this component version and automatically deploy it to our sample Dev environment.

Disclaimer: If this is your first time using the Pipeline feature in Jenkins, we highly recommend that you follow this tutorial with the Jenkins Pipeline and our Jenkins Pipeline Syntax Overview documentation. While this blog will explain the sample configuration below, some amount of personalized scripting will be required for your specific continuous integration scenario.

Set the IBM UrbanCode Deploy server configuration and authentication settings in Jenkins.

From the homepage click: Manage Jenkins > Global Settings

Scroll down to the title: IBM UrbanCode Deploy Pipeline Plugin Configuration
Specify the necessary settings here to configure an IBM UrbanCode Deploy server where the Jenkins artifacts will be pushed. Once the settings are specified, press the Test Connection button to confirm the IBM UrbanCode Deploy server can be reached. Additional UCD configurations can be added through the Add button. Note: If using the Docker Compose files and templates from GitHub, you can use the same configuration settings as above. If you name the Profile Name differently, remember it for project configuration.

Save your new configuration settings.

4) Initialize build configuration settings. Here we will configure the build tool for our simple project. In this tutorial, we will be building with Ant.

From the homepage click: Manage Jenkins > Global Tool Configuration

Scroll down until you see the Ant title.

Specify the sample configuration as below. If you use another build tool, such as Gradle or Maven, they can be initialized in a similar way.Note: If using the templates from GitHub, ensure the Ant configuration’s name is Default or remember this name for project configuration.

Save your new build tool configuration.

At this point, we have set all global configuration requirements. We will now create the Jenkins Project, set the specific plug-in properties, and import the build files into Deploy. If you have used the templates from GitHub, a Pipeline job should already exist in the Jenkins server. We will go in-depth into each of the Pipeline’s plug-in configuration examples and properties below.

Begin by clicking New Item in the upper left corner of the dashboard.

Name your new Job UCD-Pipeline and select the Pipeline job.

Click Ok

Next you will be taken the Job configuration page. Leave all properties as their defaults and scroll down to the Pipeline title.

In this text box we will define the complete Jenkins Pipeline process for the UCD-Pipeline project. This simple example is divided into three parts: Clone the source code, build the project, and import of build artifacts into IBM UrbanCode Deploy. Download the Jenkins Pipeline Script: Walkthrough 1 file and copy and paste it into the Pipeline property field.

Clone

The Clone stage will pull the GitHub repository’s source code and place it into the job runtime’s working directory. The important properties to recognize are: class, branches, and userRemoteConfigs. The class property specifies what type of repository we are trying to clone. In this case, we are pulling from GitHub, so it’s GitSCM. The second property, branches, specifies the which branch to pull from Git repository which here is the master branch. Last is the userRemoteConfigs property which specifies the exact Git URL to clone. This project will clone IBM UrbanCode’s open source DataPower plug-in.

Build

The second stage is the Build process. We use a simple build process and therefore, it can be defined in two commands. The first adds the Ant’s installation directory to the PATH environment variable. This means, when we run the following ‘ant’ command, the runtime environment will know where to look. Because we configured Ant (or another build tool) via the Global Tool Configuration, we can specify that configuration as a dynamic property: ${tool ‘Default’}. The installation folder will be dynamically resolved at runtime based on the tool specified. Once the PATH has been set, we can run the simple ant command and build our DataPower project. Note: If you defined a different build tool name replace Default with your build tool’s name and update the ant command with the appropriate call (4.c).

Import

The last stage, and the most important, is the import of these newly created artifacts to IBM UrbanCode Deploy. This last Pipeline script identifies the expected build artifacts and pushes them as an IBM UrbanCode Deploy component version. The class property defines the plug-in we are trying to use, similar to GitSCM and Default before, we are specifying the UCDeployPublisher plug-in, which is the UCD Pipeline plug-in, that we wish to initialize. Similar to the other steps, the syntax varies from plug-in to plug-in and is important to full utilize the power of the IBM UrbanCode Deploy Pipeline plugin. This Pipeline script, and others, are explained in-depth in the Jenkins Pipeline Syntax Overview documentation (link here). For now, confirm you have specified the correct siteName for your IBM UrbanCode Deploy server (3.b) and continue on to the next step.

Click Build Now from the Pipeline project’s overview page to clone, build, and import your new component version into your IBM UrbanCode Deploy server.

If any steps fail, return to the Project Configuration and make the necessary updates.

On success, navigate to your IBM UrbanCode Deploy server (https://ucd-server:8443). You should see a new component names UCD Component named UCD – Pipeline.This Jenkins build and all future builds will create component versions under this specified component.

Next Steps

For next steps, you can construct an automated deployment process using the new component version. This will need to be configured through the Pipeline syntax. The proper syntax is given in our Jenkins Pipeline Syntax Overview documentation. (link here). Commonly, an automated process will install the artifacts into a TEST or DEV server for immediate feedback. For example, if importing new plug-ins, perhaps you kick off a process that installs this plugin into a separate IBM UrbanCode Deploy test server (https://github.com/IBM-UrbanCode/Plugin-Installer-UCD). Once the proper due diligence is complete, an administrator can then manually deploy and progress the artifacts through the other environments. Using additional Pipeline scripting, you can further automate your build and deploy process by constructing components from a template or assign them to an application.

Note: If you open the UCD-Pipeline’s configuration, you will notice that source configuration is not configured. Because artifacts are being pushed, instead of pulled, into IBM UrbanCode Deploy, the component does not know how to retrieve additional artifacts. That logic, as it is preferred and explained above, is left out of IBM UrbanCode Deploy.

Freestyle Project

If “Pipeline as Code” is not your goal, this process can also be achieved through the Freestyle project. This is a good approach if you do not expect your deployment scenario to frequently change or a first time Jenkins user. Because you have already pre-configured many of the configuration (UrbanCode Deploy Server, An, etc), I will touch on many of the values. The new Freestyle Jenkins project, like the Pipeline project, it is divided into the same three stages: Clone, Build, and Import.

Clone

First, we need to clone the repository to the working directory. The below Source Code Management configuration will retrieve the same DataPower plugin GitHub repository and place it on the Jenkins server. Simply add a GitHub project name, such as our demo project https://github.com/ibm-datapower/datapower-configuration-manager, as the Repository URL parameter. All other Source Configuration parameters can remain as the default.

Build

Next, we will use the build tool (Ant) which we configured in step 4 above. Find the Add build step button and specify the Ant Version created in Jenkin’s Global Tool Configuration settings.

Import

The last piece is where we will use the Jenkins Pipeline plugin as a build step where all parameters can be given through a simplified form. The below configuration screenshot mirrors the Pipeline script that we used before. I highly recommend you compare the two configuration methods to better understand the Pipeline configuration settings. Like the previous Pipeline project, save this configuration and Build the project to see a new Component Version Import in IBM UrbanCode Deploy.

Summary: Snapshot Deployment

Now that we understand how to import newly built artifacts into IBM UrbanCode Deploy, we can then deploy them into different environments. As outline above, this would be the third part of our standard use case. However, the simple deployment has already been outlined in the Jenkins Pipeline plugin’s Usage section Instead of repeating the same walkthrough, we will take it one step further and deploy a Snapshot.

For this example, let us pretend we want to test the upgrade process for our deployable artifacts. We know how to get artifacts into IBM UrbanCode Deploy from the above tutorial and we know, thanks to the other tutorial, how to perform a standard deployment process. With this simple process, you can can easily deploy the new component versions into a Dev environment. But what if you wanted to create a repeatable and testable environment? What if you wanted to quickly spin up an pre-configured environment for someone else to test against? Snapshots enable a deployment to rollback or reconfigure to a known state. The baseline deployments allows us to initialize our testing environment with a confirmed state on every run. In this walkthough, we will use a new Jenkins project to deploy a manually created snapshot into our Dev environment.

A snapshot is a static record of the application, component versions, environments, and application process used to create the current deployed version. Snapshots are paramount in quickly performing rollbacks and configuring standardized environments. If used appropriately, automated tests can be combined with a snapshot to test various deployments against a standardized environment. Then, once the environment needs to be wiped or reset, simply deploy the snapshot again and your environment will be back to its baseline state. Our largest IBM UrbanCode Deploy users tend take full advantage of snapshots in their production deployments.

If snapshots are a new concept, than we highly recommend following this walkthrough: Creating and Deploying Snapshots. This quick walkthrough will guide you through a realistic scenario of creating a snapshot, configuring the environments, and finally deploying the snapshot through the UI. Understanding how a snapshot fits in the context of the IBM UrbanCode Deploy, will greatly help your understanding of this walkthrough. The below walkthrough assumes you have a snapshot configured and available to deploy to an application environment.

Below is a screenshot of my sample Application and configuration. If you do not know how to create an IBM UrbanCode snapshot or application, please follow the tutorial linked in the Snapshot Deployment summary. I will briefly cover the requirements here. Below is my sample Application called Jenkins Pipeline Snapshot Demo with the Dev environment and a successful version 33 deployment of the previous UCD-Pipeline component.

You can see in my example that I have deployed our UCD – Pipeline component version made in the Component Version Import walkthrough. Note: I had to create a simple Component Process that I could then run through an Application Process. This was not covered above. If you are uncertain on how to create an Application and make a successful deployment, follow the Sample HelloWorld Deployment tutorial.

Once you have an Application with a previously deployed version, create a Snapshot. Click the Snapshot tab, then the Create Snapshot button. Follow the dialog and create a new snapshot named Base Configuration. Select one of the versions that has already been successfully deployed to your Application. Remember this Snapshot name as we will use it in our Jenkins configuration. Again, if snapshots are new please follow Knowledge Center’s snapshot tutorial. The below screenshot is the sample Snapshot created using the version 33 from my previously deployed application.

Now that we have our IBM UrbanCode Deploy configuration and snapshot ready, we are ready to configure the Jenkins project.

Create a new Jenkins Pipeline project as explained in Component Version Import walkthrough steps 5a to 5d.

Download this Jenkins Snapshot Deployment Pipeline script and copy it into the Pipeline script property field.
You should immediately notice one major difference with the previous Pipeline script; the Clone and Build steps are not defined. The Jenkins Pipeline plugin is not limited to deploying locally built artifacts. It can interact with IBM UrbanCode Deploy’s API and deploy artifacts that potentially never built in Jenkins. In this example, we are simulating this scenario by taking artifacts that have been saved in IBM UrbanCode Deploy’s Codestation repository.
The main four required properties specify the Application, Environment, Application Process, and Snapshot version. The first three properties were taken from my specific Application. This properties will likely be different from you own demo Application. The snapshot name specified is the same snapshot I created manually in IBM UrbanCode Deploy. The snapshot, specified in the deployVersions property, must follow the form: SNAPSHOT=.
The deployVersions property is robust and not limited to snapshots. If you do not have a snapshot available, you can also specify components and versions. For example: if you followed the above walkthrough you could specify: UCD-Pipeline:1. (Form: :) This will deploy version 1 of the UCD-Pipeline component.
As an aside, the Jenkins Pipeline plugin is not limited to only using snapshots, it can create them too. This feature would be enabled using the createSnapshot property. In these scenarios, components and their associated versions would be specified to create new snapshots, instead of replicating the deployed snapshot.
Lastly, the deployOnlyChange property will deploy the snapshot regardless of what version was last deployed on the environment. This is a good property to set for testing, but may not be applicable for all production scenarios.
In my configuration, I will deploy the Base Configuration snapshot to the Dev environment on the Jenkins Pipeline Snapshot Demo application using the Deploy Demo application process. Once your Jenkins pipeline script is configured, click the Save button.

Click Build Now from the Pipeline project’s overview page to initiate, from Jenkins, your snapshot deployment using IBM UrbanCode Deploy.

Watch the Jenkins Pipeline view and logs to confirm it completed successfully. If any steps fail, return to the Project Configuration and make the necessary updates.

Lastly, switch over to the IBM UrbanCode Deploy to view the Application Process’s logs. Depending on your process, you may be able to see it in action. In the deployment history, you should see something similar to the below screenshot. Notice that the Snapshot value for our most recent deployment is Base Configuration which is the same snapshot I specified in my Jenkins script.

Freestyle Project

The same deployment scenario can be configured in a Jenkins Freestyle project. The below snapshot mirrors the Pipeline script configuration in the Snapshot walkthrough. As explained before, because we are specifying a snapshot in IBM UrbanCode Deploy, we do not need to specify a repository or build tool. The Base Configuration snapshot is already configured in IBM UrbanCode Deploy and contains all of the information I need to reconstruct our baseline environment.

Next Steps

Now that we can initiate UrbanCode snapshot deployments from Jenkins, the next step would be to combine each walkthrough into a single Jenkins project. Using either the Pipeline script or Freestyle form, the Jenkins Pipeline plugin can import a component version into IBM UrbanCode Deploy, deploy a snapshot, and finally deploy the new version on top of the snapshot deployment. (If using Freestyle form, this will require two instances of the UCD Jenkins Pipeline build step.) This combined approach can improve your continuous integration strategy with either automatic or on-demand environment configuration and artifact testing.

This completes the Jenkins Pipeline and IBM UrbanCode Deploy tutorial. If you wish to learn further about the syntax of IBM UrbanCode Deploy’s Jenkins Pipeline plug-in, visit the Jenkins Pipeline Syntax Overview documentation. This page will outline each sample script line with a description of how and where it can be configured.

Both Jenkins’ plug-ins are open source and accepting contributions. If you have any suggestions, questions, or modifications pertaining to the plug-in or documentation, please create a GitHub Issue or Pull Request on the appropriate repository.Jenkins Pipeline pluginJenkins Publisher plugin

New Features!

Updates have been made to the UrbanCode Deploy Jenkins Pipeline plug-in! Starting in plug-in version 2.5, projects can specify descriptions and application process requests properties within the initial configuration. This allows for more dynamic and complex deployments based on the result of Jenkins artifact builds. If any required application process request properties are not found, the Jenkins step will fail and alert you of the forgotten properties.

For many organizations, one of the biggest bottlenecks in automating the delivery pipeline is related to an inability to automate testing as part of the deployment process. And as teams may have forged ahead to automate the deployment of software change that value can be quickly diminished when things stall due to a lack of test labs being available or when an excessive number of tests are being run manually. That of course, is once all the software changes have been made available.

While I have been evangelizing the integration of deployment and test automation for a while, one of the key findings in the “State of the Software Testing Profession Results 2016-2017” survey results, recently published by Techwell, is that it is an automated world and testers get to live in it. Meaning, the role of the tester is becoming more technical, testing must transform to meet the needs of modern software projects, and there is increasing need for more automation.

So, as more and more test professionals are working to bring automate testing capabilities into their organization, isn’t the next logical step to include those automated tests as part of the automated deployment process.

Let’s take a step back and assume that you have heard “better, cheaper, faster” at least once and for many it may be far too often. However, integrating automated testing with deployment automation delivers positive results with respect to better cheaper faster. Automated tests can be run repeatedly and consistently freeing up resources to execute other types of testing (e.g. exploratory testing) expanding the level of testing. Automated tests should be part of an automated deployment process to help close the feedback loop as the sooner test execution results can be shared across the delivery team, the sooner any issues can be identified and triaged. The faster defects are discovered, the cheaper they are to fix. So, better, cheaper, faster is still a great way to describe, at a “motherhood and apple pie” level, the end goal for many businesses. Deliver better software, faster than the competition, at a lower cost to the business.

This is where IBM UrbanCode can help. The blueprint designer functionality, available in UrbanCode Blue Print Designer, allows teams to treat test lab infrastructure as code. By creating blueprints or patterns of what the test lab needs to contain, new environments can be provisioned (or decommissioned) on demand. Middleware can be installed and configured. Testing across multiple environments can be run in parallel. There are no more excuses!

Application deployment processes, modeled in UrbanCode Deploy, can be triggered as part of the provisioning process ensuring the latest components are available for testing. And automated tests can be executed as a step in the deployment process providing instantaneous feedback on the functionality, performance and/or security of the application.

However, in an IT world where software changes are being implemented by multiple delivery teams and at different development/release cadences, all the pieces needed for testing may not be available. Deploying virtual services or “stubs”, created in IBM Rational Test Workbench, to IBM Rational Test Virtualization Server can make the unavailable available for the purposes of testing. And through the UrbanCode Deploy plug-in, these stubs can be remotely turned on and off simulating the missing software or system allowing applications to be tested end to end.

IBM UrbanCode’s extensive plugin ecosystem, offering support for many different test automation solutions along with many other technologies, makes adding automated testing to be part of a continuous delivery process easy. Simply download the test automation plugin you need, add it your UrbanCode Deploy server installation, and the ability to include test automation in your deployment process is at your fingertips.

Using the UrbanCode plugin means that you don’t have to deal with the complexity of command line syntax. All you need to do to get started is drag a test automation step to the deployment model from the step palette in UrbanCode Deploy’s graphical process designer, type in your specific parameter values, wire in the step, click save, and let UrbanCode Deploy do the rest – better, cheaper, and faster.

To learn more about shifting left and to see the integration between IBM UrbanCode Deploy and IBM’s Rational Test Automation in action, watch the video.

The latest version of IBM UrbanCode Build version 6.1.3 is now available containing performance enhancements and new features. Below are a few of the changes in version 6.1.3. For more information, see What’s new in UrbanCode Build 6.1.3.

Enhancements

The Search user interface has been updated to improve searching for build lives including additional filtering and sorting on search fields.

Managing build labels is now more flexible. You can remove unused labels from the server. Assigning labels can be done from the search page for build life. After locating the desired build life you can assign it to a different lable. You can also create a new label and assign it from the Search page.

User accounts can be deactivated when no longer needed. Additionally, user accounts can be permanently deleted if the account has no history in the system.

Plug-in Enhancements

Plug-ins are automatically backed-up with each upgrade and downgrade. Backing up plug-ins provides you the ability to restore a plug-in to a previous version.

Several new plug-ins such as the ones listed below are available for UrbanCode Build that you can use to: