Over a million developers have joined DZone.

UrbanCode: Deploy Applications With Time Stamps in File Names

Some continuous integration processes produce artifact file names that contain a time stamp or other variable suffix. It is better to store the time stamp or build ID elsewhere. Let me show how to avoid this problem in IBM UrbanCode.

· DevOps Zone

Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs

Some continuous integration processes produce artifact file names that contain a time stamp or other variable suffix. It is better to store the time stamp or build ID elsewhere, for example inside the MANIFEST.MF of a JAR file. However, in practice, continuous integration processes often add a suffix to file names. When configuring IBM UrbanCode Deploy processes for deploying such files, you need to account for this suffix in the file name.

One way of doing this is to create a version property that stores the name of the file. Then you can refer to this version property during deployment.

For example, if you are using the WebSphere Application Server – Deployment plugin, you have a component template called WebSphere Enterprise Application. This template uses a component property that is named earFile.

Image title

You cannot give a fixed value to this property in this case because the file name will change based on the time stamp.

Here’s one way to fix this problem:

1. Create a component that is based on the WebSphere Enterprise Application template, with the following details:

  • In the Application Name field, specify a constant value, EAR2 in this example.
  • In the Ear File field, use a reference to the version property in the component template: ${p:version/earFile}
  • Leave the Source Configuration Type field blank.

Image title

2. Add a version property to the component with the name earFile. The property name must match the property reference you specified in the component configuration (in this example, ${p:version/earFile} ). Make this property required, as shown in the following figure:

Image title

3. Use the command line client to create a version for this component. In this example, the component name is C and the version name is v1.0:

udclient -weburl https://localhost:8443 -username myuser -password mypassword createVersion -component C -name v1.0 


4. Use the following command to add the artifacts to the version and copy them to CodeStation. In this example, the built artifacts are in the folder C:\temp\C\v1.0:

udclient -weburl https://localhost:8443 -username myuser -password mypassword addVersionFiles -component C -version v1.0 -base C:\temp\C\v1.0 


5. On the new version, specify the name of the file on the earFile version property. In this example, the name of the EAR file is C:\temp\C\v1.0\EAR2_20160722.ear:

udclient -weburl https://localhost:8443 -username myuser -password mypassword setVersionProperty -component C -version v1.0 -name earFile -value EAR2_20160722.ear  


The output of the command looks like the following code:

{
 "id": "ea01c137-3a3e-4722-8670-c4090a11831a",
 "name": "earFile",
 "value": "EAR2_20160722.ear",
 "secure": false
}

In a typical continuous integration/continuous deployment pipeline, the build process would run these commands after the build is complete. 

6. In the component version, verify that the property earFile appears, as shown in the following figure:

Image title

7. Create an application. You will use this application to deploy the component version to WebSphere Application Server.

8. Add the component to the application.

9. On the application, create an application process and add the Install Component step.

10. In the settings for this step, select the component and the component process Deploy EAR with User/Group Mappings… as shown in the following figure. This process is defined in the component template.

Image title

11. Create an environment in the application and add a base resource that contains an agent and the discovered topology of the target WebSphere cell. Add the component under a server or cluster contained in this cell, as shown in the following figure:

EAR2_20160722.ear


Image title

click for a clearer view


13. Check the WebSphere Application Server administrative console to verify that the EAR is installed successfully. The EAR appears with the fixed name EAR2, as you specified in the component configuration, as shown in the following figure:

Image title

Now you can configure your continuous delivery system to use this process to deploy the EAR file, taking into account the suffix on  the file name.

Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.

Topics:
continuous integration ,urbancode ,websphere application server ,ibm ,property ,integration ,enterprise ,websphere ,application

Published at DZone with permission of Lara Ziosi, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}