How IBM DevOps Deploy uniquely integrates with Traditional WebSphere

Author: Randy Langehennig

Date: August 7, 2023, v1.1

Overview

This document attempts to highlight the unique capabilities that IBM DevOps Deploy provides to our clients as they bring Continuous Integration and Deploy DevOps practices to Traditional WebSphere targets. 

The key areas to highlight include:

• ·      Discovery of your WebSphere cell
• ·      Ability to capture WebSphere configuration and lift and shift this to new instances
• ·      Excellent capabilities to deploy applications at different scope levels

IBM has clients across the globe using this product to deliver WebSphere applications across many different industries including Banking, Insurance, Distribution, Government, and much more.     I have personally helped to implement the solution to support Traditional WebSphere targets for a client in the Energy sector and they are very pleased with product for many years.

WebSphere Automation Plugins

Before we get started reviewing some of the key features, we must tell you that IBM UrbanCode Deploy comes with plugins for Traditional WebSphere that are free of charge.   They are fully supported by IBM and come embedded with the scripting needed to perform various functions. 

The plugins include WAS – Configure, WAS – Deploy, and WAS – Install as you see from a list of Automation Plugins below:

These plugins provide the building blocks for creating automated processes to help our clients with installation, configuration, and deployment of WebSphere applications.

WebSphere Cell Discovery

One of the nice features that we bring with our WebSphere automation plugins is the ability to discover your existing WebSphere cell topology.   When you install a IBM UrbanCode Deploy Agent on a WebSphere Deployment Manager system, our agent will detect this is a dmgr instance and will allow you to discover the topology.

Here is an example from a QA instance of WebSphere where the discovery will find your nodes, clusters, and servers:

With this discovered, we automatically pass parameters to processes for you like the cluster name, the server name, and more.   This convenience is so helpful to our clients.

WebSphere Application Deployment

IBM UrbanCode Deploy provides some excellent capabilities to help our clients in the area of deployment.   UrbanCode Deploy leverages an Application Model which is very powerful.   The Application Model consists of these three items:

1. Components (examples: EAR, Properties, and Database Updates)
2. Processes
   1. Component Processes (e.g. deploy EAR, deploy properties, update database)
   2. Application Processes (these orchestrate the individual component processes to execute in the correct order)
3. Environments (e.g. DEV, STAGE, and PROD are environments we deploy the applications to)

For example, this shows an example application called "PlantsByWebshere":

One of the real strengths of UrbanCode Deploy is the ability to leverage component templates.   If they way you deploy an EAR for this one application is the same way you will deploy many other EAR files, then you can create the template with a generic process which will benefit you in two ways:

1.     You can quickly on-board other like applications and components

2.     You have one place to go to make updates from a maintenance perspective when changes are required to the process

Here is a screen capture of an example WebSphere component process using UrbanCode Deploy and our WebSphere plugins:

Since your application can consist of one more components, you can configure a high-level application process to coordinate the deployment and make sure each component is deployed in the correct sequence.   Here is an example:

Many of our clients love that IBM DevOps Deploy can handle complex deployment scenarios, has built-in support for semaphores (or locks), and much more as shown above.

Another key feature for IBM UrbanCode Deploy is that it tracks inventory of what is deployed in each target environment.   Here is another screen shot showing the component versions deployed to our DEV environment.   Typically the version label is a build tag for traceability back to the build and the version can include a link back to your build system, git repository, and more.

Inventory allows you to see when a new version was deployed to an environment, what used to be their prior, and how one environment compares to another:

Further, we do have a very nice concept of quality gates you can leverage to ensure good quality code is flowing from one environment to the next.   Here is a screen shot of an example:

Many of our clients use these gates to help with their audits to help prove to auditors that all the proper steps were followed.

Finally, there is an excellent history of all deployments you can review as well as trail of audit for each deployment that is so beneficial.

WebSphere Configuration

Let’s say you needed to perform a lift-and-shift of your existing WebSphere cell to a new platform.   You can use the WebSphere Configuration plugin to capture WebSphere configurations for the existing WebSphere cell prior to the shift to the new environment.   The configurations will be captured for your cell, cluster, and server scope in a JSON format.   This can be referred to as an exemplar configuration.

Here is a screen shot of cluster configuration that was discovered for my WebSphere cell:

The configuration that is captured is done in a version agnostic manner.   This means it can be used for transfer of configuration from WAS 8.5.5 to WAS 9.0 and some additional steps may be required to support any new configuration options.   Please consult with the IBM team and we can provide guidance.  

Here is an example of what the configuration looks like at the Cluster scope in a JSON format:

This configuration could be made into a reusable template by removing hard-coded values in the configuration.   Here is an example of a JDBC resource with a hard-coded string value:

Using the WebSphere - Configuration plugin, you can replace a hard-coded value with a token to make it reusable.   Here is an example:

You can then set a property value and this value will be inserted at the time the process applies the configurations to the target.

Finally, once configurations are applied, we can compare the live environment to the expected exemplar configuration to check for differences and report on it.

When you view the property differences, you will see a dialog like this one which shows that someone changed the name of the JMS queue from DEV_QUEUE which was the expected value:

Summary

In summary, IBM UrbanCode Deploy has been uniquely positioned to help our clients that require DevOps features to support Traditional WebSphere.   Our plugins to support deployment, configuration, and installation provide our clients with the building blocks to create automated and repeatable processes.  For many of our clients,  they can focus on automation and get out of the business of homegrown wsadmin scripting business by leveraging our IBM plugins that are fully supported by IBM.

I hope you found this to be a good introduction to the topic and please reach out to your local IBM contacts for further information.