OSB Release Management Utility

Agile methodologies have increased radically the numbers of release events in organisations where it has been adopted.  Both development and operations teams need to collaborate more closely during production release events requiring more than ever the right supporting tools.

How many times have you been asked what has been deployed in environment X? 

If you are using CI tools and doing release management properly it should be a straightforward answer. However, software deployment comprises a set of steps involving multiple parties. As a result, the process isn't entirely automated requiring human intervention which is susceptible to errors.

Imagine you have just delivered an OSB Production bundle to the operations guys (DBAs, Weblogic Admins…).

How can you prove that the expected jar has been deployed without looking at the source code or running any tests ?

We are using a custom Release Management Utility that saves us a lot of time and headaches ☺

• No third-party software required; It uses Hudson, SVN, Maven and OSB
• Allows users without technical knowledge to view what’s deployed
• Identifies project changes between sprints
• Track back to source code based on SVN revision
• Displays build date and version for each individual project

Overall Architecture

Similar to a JAR file's manifest each OSB project will contain a build-version.xml file where all the required information is stored. When the build process is triggered Hudson pulls the project from SVN and the code is built. Additionally, maven replaces the Hudson runtime variables on the file ensuring the creation of a unique and traceable JAR. Once this is done, we aggregate and display the information as a web page to the user. We can now hit the OSB endpoint in any environment (DEV, SIT, UAT, PERF and PROD) and understand easily what’s actually deployed.

Implementation Details

Hudson holds runtime variables for each job execution which we use to replace the build-version.xml using the maven plugin “com.google.code.maven-replacer-plugin”. A snippet of the pom.xml can be found here. Additionally, a global variable called RELEASE_NUMBER was added to store the actual sprint number. This variable is incremented manually on the beginning of each sprint.

Once a project is deployed Weblogic stores the files under the following path:

<DOMAIN_HOME>osb/config/core/<PROJECT_NAME>/

All paths for the projects we would like to report are stored in a properties file.

<urls>

    <buildURL>osb/config/core/ProjectA/build-version.xml</buildURL>

    <buildURL>osb/config/core/ProjectB/build-version.xml</buildURL>

</urls>

The Reporting service provides data through an XML or HTML proxy.

XML Proxy

Regarding the properties file, the Java Callout reads all the build files and aggregates the information into a single xml. Beware that OSB wraps the files into CDATA and some parsing needs to be done.

HTML Proxy

Reuses the XML proxy and applies XSLT transformations to convert the data into HTML.

Simple extension

Having this implemented, we questioned ourselves about an easy way to compare this information across environments instead of hitting all the endpoints and fetch it manually.

So, from the delivery box we execute a Java HTTP client that consumes the XML proxies and outputs the comparison result (based on the SVN revision). As a result, code propagation between environments is more clear and traceable.

Note: Make sure you have connectivity to all the environments from the delivery box.

The revision of each project is compared across environments and the example below shows that two projects are out of sync.

Thanks to Wayne Highland and Kevin Ryall that participated on the development of this utility.

Drop me an email if you have any questions :)