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 UrbanCode famliy of products (Build, Deploy and Release) boast an impressive array of over 350 plugins. UrbanCode Deploy alone has 175 plugins from partners, our dev team and the community that can help you integrate deployment automation into your existing toolchain without having to “rip and replace.”
Join us to learn about some of the latest and greatest plugins for Docker, containers, testing, application security and monitoring and how to write your own plugins and contribute to our growing community. Then we will discuss the UrbanCode mobile iOS app and how you can use it to view and contribute to your organization’s deployments and major releases from anywhere you can use your cell phone or tablet (pretty cool). Then stick around for Q&A and ask our development team leads any of your questions!
Using JSON snippets to add objects to a configuration
To add an object to a WebSphere Application Server configuration, create a JSON file that represents the object. Use the provided WebSphere – Create Configuration Snippet step to create snippets. For example, let’s say you used the WebSphere – Create Configuration Snippet step to create a JDBC provider snippet. Let’s say the snippet file is named jdbcProvider.json.
If you are storing configuration data as component version artifacts, add the JSON file to the component version artifacts in the cell directory, as shown in the following screen capture:
When the Apply process runs, the Cell.json and jdbcProvider.json files are merged and applied to the target instance of WebSphere Application Server.
When you use the WebSphere – Create Configuration Snippet step to create snippets, JSON paths and hierarchy are managed automatically for you. If you want to create snippets manually, read on for more information about configuration data JSON structure.
The JSON information that represents a WebSphere Application Server configuration resembles a directory hierarchy. For example, the following JSON information represents three JDBC providers:
You can think of the four previous JSON entries as a directory hierarchy, with the first entry representing a folder and the other entries representing objects contained in the folder.
--- JDBC Providers
--- first JDBC Provider
--- second JDBC Provider
--- third JDBC Provider
This structure is reflected in the path value for each of the JSON entries.
The parent JSON entry is required, and there must be only one parent entry. Keep this in mind when creating snippets. For example, if you use a snippet to add a JDBCProvider object at the cell level, the final JSON file must contain the following JSON entry only once:
When you use the WebSphere Application Server – Configure plug-in, WebSphere Application Server configuration data is stored in JSON format. You can split up the JSON file and add entries to the JSON file by using snippets.
Important: The path to the JSON file must be unique for a configuration objection. For example, an entry for a JDBC provider might looking like this example:
When you work with snippets, extract a piece of JSON from an existing config file, and then use it as a template to facilitate adding objects to a configuration. If you create a snippet this way but fail to ensure the path is unique, some configuration objects are ignored. For example, assume that a user wants to add a second JDBC provider to a configuration, which already has a JDBC provider. The user can complete these steps:
Extract a copy of the JDBC provider configuration from the full configuration data. (Let’s say it’s the preceding JDBC provider.)
Change the JDBC provider configuration in some way, but leave the path as it is:
The WebSphere Application Server – Configure plug-in stores WebSphere Application Server configuration information in a series of JSON files. You can divide the JSON files into smaller, manageable pieces and use the small JSON files, or snippets, to create and modify configuration data. You can then tokenize values in JSON snippets, and use processes to replace the tokenized values with IBM UrbanCode Deploy properties. By keeping component artifacts managed in a source control system, you can build a library of JSON snippets that users can apply to WebSphere Application Server configurations.
The snippet files can contain tokenized values, such as the values shown in the following code. In this example, tokenized values start and end with the at symbol (@).
To easily tokenize values in a snippet, use the WebSphere – Templatize Snippet Configuration Data step. This step can replace values such as the cell name, server name, and so on with tokens. Additionally, the User Defined Tokenization property of this step runs a find-and-replace operation on text in your configuration data. You can easily use the User Defined Tokenization field to convert values to tokens in your configuration data.
The following diagram shows a process that retrieves a snippet from source control, replaces the tokenized values, and then checks in the snippet to source control and updates the component version.
IBM UrbanCode Deploy properties (environment properties, component properties, resource properties, and so on) are used to replace the tokenized values. The following examples show the use of component process properties:
When the process runs, you are prompted to enter values for the component process properties, as shown in the following screen capture:
In this example, the tokenized values in a copy of the JDBCProvider.json snippet are replaced, and then the snippet is moved to cell directory under the cell component artifact.
Instead of replacing all values as shown in the previous process, you can leave some values tokenized, and then use properties to set those values when the Apply process runs. For example, if the JVM heap size property changes for different environments, you can leave the JVM heap size tokenized in the snippet. In the Apply process, replace the token with a corresponding property.
The recent enhancements to the plug-in include support for creating collectives, joining servers to the collective as members, registering hosts with the collective, uploading files to registered hosts, and starting and stopping servers in the collective by using the Liberty collective controller.
The Create Collective step creates a new collective and configures the specified server as the collective controller.
The Join Collective step adds a Liberty server as a member of a collective.
The Register Host step registers a new host with a collective.
The Unregister Host step unregisters a host from a collective.
The Update Host step updates read and write paths for a registered host.
The Upload File To Collective Host step uploads a source file to a host in the collective.
The Plants1_artifacts.zip file contains an example IBM® UrbanCode™ Deploy application that creates and configures a WebSphere cluster, and then installs the PlantsByWebSphere application on the cluster. The processes in the UrbanCode Deploy application use the multiplicity feature to create the cluster.
Note: This example requires IBM UrbanCode Deploy version 6.2.1 or later.
In IBM UrbanCode Deploy, click Applications > Import Applications, and then import the example application archive. Select Import with Snapshots. For the Upgrade Type lists for application template, component, generic process, and resource template, select to upgrade if the object exists, as shown in the following screen capture:
Create a top-level resource directory, and then add the agent that is running on the WebSphere Deployment Manager to the new top-level directory. The automatic discovery process runs.
Edit the new WebSphereCell object to add the user ID, password, and port information, and then run topology discovery on the cell.
Click Show > Resource Roles, and then drag a WebSphereCluster object from the roles pane to the ServerClusters directory in the resource tree. Give the WebSphereCluster object a name such as PlantsCluster.
Add the PlantsByWebSphere and PlantsClusterConfig components under the PlantsCluster cluster. When you add the PlantsClusterConfig component, you must specify values for the SERVER_COUNT and NODELIST role properties. Specify 1 for the SERVER_COUNT property and one or more application server node names in the NODELIST property. Change the value of the WC_defaulthost endpoint in the ENDPOINTPORTMAPPINGS field from 50700 to 9080. To use a value other than 9080, you might need to add the value to the Virtual Hosts->default_hosts->Host Aliases section of your WebSphere environment. Check that the other default values that are specified for the ENDPOINTPORTMAPPINGS field do not conflict with any existing ports in use in your WebSphere environment. After you add the components, the resource tree looks similar to the following example screen capture:
Go to the Test environment of the PlantsByWebSphere application, and then click Add Base Resources to add the new resource tree as the base resource of the Test environment, as shown in the following example screen capture:
You can now run the ConfigureClusterAndInstallPlants application process on the Test environment. Select the Release1 snapshot in the Run Process window, as shown in the following screen capture.
The process runs and installs the PlantsByWebSphere application installed into the new cluster. Access the PlantsByWebSphere application by opening http://node_name:port_number/PlantsByWebSphere in a web browser. For node_name, use the host name of one of the application server nodes that you specified in the NODELIST field in step 6. For port_number, use the value of the WC_defaulthost endpoint in ENDPOINTPORTMAPPINGS field from step 6.
You can use the Get Compare Result step in the WebSphere Application Server – Configure plug-in to automate comparisons with live WebSphere instances. Use this step after a WebSphere Configuration Compare step to generate comparison data in JSON format. After the compare step runs, the comparison data is available to subsequent process steps. For example, you can add a step that sends an email to the relevant staff to warn them that a change was found.
A Boolean value where true means that changes were found in the comparison JSON information and false means that no changes were found between the configurations.
A hyperlink reference to the application process request that ran the step. Use this link to view more detailed information.
Create a component process where the WebSphere Get Compare Result Step runs after the WebSphere Configuration Compare step. To learn more about the WebSphere Configuration Compare step, see the plug-in documentation. The following screen capture shows an example process:
After you attach the Get Compare Result step to a compare step, run an application process that calls the component process. Go to Applications, select your application, and then deploy and run the full comparison application process, which in turn runs the updated component process from within Cell Config.
After the application process request is complete, you can view the results. Go to the application process request that ran. (If you navigated away from the process while it was running, you can return to it by clicking the History tab on the application environment page.) Drill down to the Get Compare Result step, and then click Input/Output Properties on the right (the white notebook paper icon). For more information on the function of the output properties, see Output properties. The step uses two input properties: appProcessRequestId and compProcessRequestId. These properties are used to retrieve information from the previous step. These properties are set automatically and typically you do not work with them directly.
What to do next
From here, you can attach other process steps to the Get Compare Result step. For example, you can attach a process step that sends an email alert if the Boolean areDifferencesFound property from the compare step is true or false.