Genesis

Hussein Badakhchani’s Blog November 1, 2006   1:37 AM

Those of you who read my blog would be aware that around late November of last year I decided our existing build process had to go. You can read my original rant here. Well I am please to report that after much discussion we bit the bullet a decided to scrap our build process and embark on creating a new process that we hoped would meet the increasing demands being made on the infrastructure team to build and deploy the numerous WLS domains that we manage. We have been using the new build process (which we call choom) for almost a year. In that time the demands to create new environments and support new versions of WebLogic, Apache and other middleware applications have only increased while our team has dropped in size from six to two people. If you are considering different approaches to building and deploying WLS domains I hope you find this and the next few entries useful. If you think these ideas are rubbish I want to know why?

To start with lets define some of the key requirments for our build process. The build process must:

• Create a complete WLS domain and scripts to distribute and install the domain onto multiple machines.
• Be fast. It should take no longer than a few minutes to build, distribute and install a WLS domain. This a key measure of the performance of a build process. The vast majority of WLS domains I have seen can be built and distrbuted in under a miniute on a desktop pc.
• Enforce architectural and design decisions and verify the configuration by checking the completed domain before it is distributed.
• Be simple to use. Anyone with basic unix skills should be able to build and deploy a domain after a 5 minute tutorial.
• Be able to build Apache, WebLogic and any other application maintained by the support team.
• Be simple to maintain. The build process should not require a team to support it. The process of adding new environments or applications must require no special skills.

With these requirements in place we invited BEA to help us evaluate different build approaches. The debates were always heated as everyone involved knew we had to get this right or we would end up in a mess. To outsiders it may well have seemed that the team was about to crack but in my experience civil and plesant technical discussion is often a sign that participants don’t know what they are talking about or don’t care. We whittled down the contenders to a) using WLST to dynamically create the domain and b) Create template domains and use ANT to “copy filter” the templates. We opted for ANT option for many reasons but the deciding reason was simple, WLST can only build WLS, the ANT option gave us a consistant method for building any application we wanted.

The next step was to create a template domain and define the properties. The customer had two sites, a live site and a contingency site. These sites were home to the production environment, a domain that spanned two machines. We would supply arguments to the build script which would determine which property files were loaded and used to create the domain. We had to group related properties together in their own files and we came up with the following files:

• common.properties – Used by all builds prefix=Common.
• mydomain.properties – Domain specific prefix=Domain
• production-live.properties – Production environment and live site prefix=Environment.
• production-cont.properties – Production environment and contingency site prefix=Environment.
• machine-live1.properties – Machine 1 in the live site prefix=Machine.
• machine-live2.properties – Machine 2 in the live site prefix=Machine.
• machine-cont1.properties – Machine 1 in the contingency site prefix=Machine.
• machine-cont2.properties – Machine 2 in the contingency site prefix=Machine.

To build the domain one would execute the following command:

ant -Dproduct=weblogic92 -Dsite=live -Ddomain=mydomain -Denv=production

The build loads the correct set of properties based on these arguments. This is a pretty standard approach familiar to anyone that uses ant, it looks like this:

<property name="properties.dir" location="${basedir}/properties"/>
<property file="${properties.dir}/common.properties"/>
<property file="${properties.dir}/domains/${domain}/${domain}.properties"/>
<property
file="${properties.dir}/domains/${domain}/environments/${env}/${product}/${env}-${site}.properties"/>

I’ll explain the directory structure in my next entry, to round off this entry I want to explain one of the problems with this standard ant approach and how we resolved it. If you have ever had to locate a property to change it’s value you have probably had a few hours of your life wasted by having to locate that property because it is defined in multiple files and ant can be configured to inherit properties. Our old build process didn’t have a consistant hierarchy which compounded the problem. It could take days to make a change to a single property! We were burned so badly by this that we decided there would be no inheritance of property files in Choom and that every property name would conform to a nomenclature that would indicate where that property was located in the build file system. For instance, if you were looking at a template of the config.xml you would see something like this:

    <ssl>
      <name>@Domain.admin.Server.Name@</name>
      <enabled>@Environment.admin.Server.SSL.Enabled@</enabled>

Any property prefixed with Domain corresponds to the domain level properties defined in mydomain.properties. If it’s prefixed with Environment you know it has to be in the production-${site}.property file for that site. Now we can locate and change the value of any property in seconds. For me this is a key metric to use in determining the performance of your build process. If you find it takes longer than a couple of minutes to make a simple configuration change in your build, alarm bells should start ringing.

In my next entry I will discuss the directory structure of choom and the templates. We gave alot of thought to the directiry structure of the build process. We wanted it to be intuative, consistant and to reflect how we perceivethe architecture our domains.