Databases also have source code that is compiled. While there are clear differences between compiling for a database and compiling binaries for a hardware/operating system combo or virtual machine, there are many similarities.

The clearest difference between a database build and a C or Java build is that there are no easy to identify output files. With C or Java, you end up with new files that you normally transfer to a runtime environment. With databases, it is usually not obvious what is happening after you make your changes.

But databases do have source code. The first step is to recognize that DDL or Oracle PL/SQL is every bit as much source code as C or Java source. This source should be managed in version control and subject to the same life cycle management and controls as any other application source.

The next step is to think of the SQL/DDL/PL interpreter as a compiler. Oracle’s interpreter is sqlplus, while both Sybase and Microsoft SQL Server have a program called isql.

Now a trick is required. By using this trick, one can easily manage database builds with traditional file-based build systems. The concept behind the trick is to use a proxy file. A proxy file is a file that represents the output of a database compile in the build area, even though the database interpreter itself did not create one. Let’s say you want to make a change to a database table by applying an ‘ALTER’ statement. Put the statement in its own file. This is the source code. Now operate on the source code by passing it to the interpreter in the same way you would pass C or Java code to a compiler. Whereas the compilers create some kind of output files, you have to create your own fake output file. But this file will have the timestamp of the compile operation, which is also (approximately) the last modified time of the table. You can now manage database changes in a traditional incremental make system.

With make, you can perform an incremental build by assuming that output files have later modification times than the source code if the build is up to date. If a source file is found to be modified after an output file, make can execute the minimum amount of necessary commands to rebuild any output files depending on the newer source.

You can get fancy pretty quickly from here. Most sophisticated database systems keep track of the last modified time of each table. Instead of pulling your own timestamp from the operating system you could query the database after you apply an operation for its timestamp value and use that for the modification time of the proxy file.

If your proxy files serve as a representation of a table or a view, you can even create a full set of proxy files without any source code as your starting point. This gives you an audit point if you have a secure file system for your build area. You can create a set of proxy files initially and then later compare the database timestamps with the proxy file timestamps to see if any alterations were made outside of the build system.

We’ve adapted the OpenMake product to manage database changes for several companies. OpenMake’s dependency management really helps to apply database changes in the correct order, insuring ALTER statements are applied before a procedure definition, for example. The make‘ish timestamp checking of OpenMake allows for incremental changes. This is handy if something breaks half way through. If you’ve applied your CREATE statements and something breaks afterwards, you know full well, re-applying the CREATE statements will produce an error message. This is not a real error, because the table is already created as part of this change. An incremental system, possibly with proxy files, will know that the CREATE statements completed successfully and there is no reason re-apply them. The incremental system will pick up where it left off, so that the source code can be corrected, re-introduced to the build area and then the changes applied from the point they were last successful.

Having an incremental system for making database changes allows only real errors to come through and removes the intelligent person from having to interpret error messages and determine if they are real or not. This allows for a much greater level of change automation and one reason I am eager to help develop this part of the product.

We moved from Joomla to WordPress and we are all very happy and excited about the new capabilities of our blog site. Pardon our dust as we had a short break and the promise of weekly posts for some blogs have not materialized.

Our fearless leader is tickled about using LiveWriter to post (Stephen’s Post), while I think I’m going with Word 2007. LiveWriter is great, but I want to save my posts offline in a way similar to my other writing. I write a lot and am used to Word.

Only a few days after reading the article, “Perl is dead. Long live Perl!” on O’Reilly (JT’s Article on Perl), I met JT at the MadMongers meeting. MadMongers is the Perl users group in Madison, Wisconsin. Good timing!

Often, outsiders complain about the use of symbols in Perl. Perl regular expressions are notorious for this. While anyone can learn these representations, if you are new to Perl, some parts of code can look pretty Greek.

This has been followed by an amusing article on the awkward and confusing nature of English (Is it time to replace English for Code?). Or rather, the English comments accompanying Perl code are more to blame than the code itself.

In my experience, the symbolics in Perl are not a hindrance to new users. In fact, Perl is so accessible to novices that it is easy to wind up with very bad scripts. Almost anyone can write a simple Perl script and very often people claim the title “Perl programmer” with very little experience.

JT Smith has been called an “unsung hero of using Perl in business” for his company’s successful WebGui product. Since Perl is a big part of the OpenMake Software product line, I think we deserve some credit as well. If not “unsung heroes” because our products use C and Java as well, then perhaps “unsung sidekicks.”

Rest assured Perl is alive and well and expanding and becoming more useful every day. I subscribe to the CPAN updates on use.perl.org and there are 15-30 Perl module updates daily. Just one indicator of activity. (And, unlike Java, there is automated community release management to keep dependencies straight.)

How did Cruise Control and Maven lead to Mojo and Meister? We listened to developers’ struggles with CC and Maven and the result so far is Mojo and Meister. Read on for details…

I was working with some developers on standardizing their builds on Openmake (precursor to Meister) and asked them about their experiences with Cruise Control and Maven for Java builds. They had been using Cruise Control to call Maven. While there are a lot of different bits of functionality in these tools, I want to focus on the repeatable processes they are set up to control. Cruise Control (CC from now on) was set up to check out files from CVS and initiate Maven which did the build and ran JUnits.

So CC had a repeatable build loop of 1. execute according to schedule, 2. run a CVS check out, 3. initiate Maven, 4. report results.

Maven itself had its own, more specialized build loop of 3a. compile, 3b. run Junits, 3c. “package” the Java, or create the deployable archive. (There were a few more steps, but I’ll skip it to maintain focus)

The resulting integration involved nested build loops. CC ran one build loop, and one of the steps in the CC build loop was a multistep Maven build loop. This cumbersome “integration” resulted in a typical build log. If you’ve never read a build log, then maybe you are reading the wrong Blog - they are typically very long, somewhat cryptic and it is usually tedious to identify specifics of commands and errors when there is a problem.

So, how can we do better? Well, we can “flatten” the nested build loop into a single repeatable build loop where every step is reported equally and then some. Mojo is roughly the equivalent of CC with a graphical build monitor to flag in bright red steps that fail in an event summary view in Eclipse or a in a standalone Eclipse RCP client. Meister adds to Mojo the Maven bit. The difference is that Meister includes Mojo, as if CC and Maven were one fully seemless product. With Meister, all steps in the build loop are treated equally. This includes the CVS check out as well as the compile step for a particular JAR. When an error is flagged in red on the Workflow Monitor the developer clicks on the red line and the (HTML formatted) build log is pulled up with the focus precisely on the error location. This provides the transparency the developers were looking for in the build loop and it saved them a lot of time poring through tedious logs.

This is what we mean by community-developed. We work closely with developers in the field and find out what is a productivity killer (and annoying) and listen to what they say about what they would like to see improved. We take their feedback and directly put it back into product development. For me it is really rewarding to help improve the build process for developers. Developers tell me they appreciate someone listening and working to help them be more productive. I wonder if it is a kind of social work for builds?

I heard this from some developers today who confirmed the existence, by indirect evidence, of willful tampering of Java archives by gremlins using Ant. There is speculation that they live inside their own plug-in inside WebSphere Studio Application Developer.

Developer A, we’ll call him Nick (because that’s his name), came into our room to work out some tweaks with Openmake targets. He told us all that they’d been working on some problems with runtime errors getting the dreaded Major-Minor version error: “Unsupported major.minor version 49.0.” This usually indicates that you have compiled something with a 1.5 JDK but are running it under a 1.4 JVM.

The archive they were deploying was created wholly inside a workspace managed by WebSphere Studio Application Developer (WSAD) but built by Ant using IBM JDK 1.4.2. Now, WSAD by default launches under a 1.3 JVM, so there is no hint of a simple conflict of JVM’s. They actually traced the issue down to a few class files in the deployed archive that had a 49.0 class versions by using a byte editor. So only a subset of the classes compiled by Ant were affected! But, if they created their own Jar file at the command line through the Windows command prompt using the same exact files, the Major-Minor problem didn’t appear. This means the classes were altered at the packaging step - NOT the compile step!

Harking back to my pain with multiple versions of Java over the last decade, I interrupted this fine tale and asked with a haughty tone “Is a 1.5 JDK installed anywhere on the machine?”

“Yes”, he answered, and the problem, he said, was resolved by uninstalling the 1.5 JDK. We all then had a nice knowing chuckle. Then we questioned Sun’s use of the registry in Java and how the use of the registry changed with each release, forgetting, in fact that the problem happened under an IBM JDK. We also talked about the practice of dumping of java.exe under the windows/system32 (%SYSTEM_ROOT%) directory and how that could trip you up. You never knew if it was a Microsoft java.exe or a Sun one, and if it was Sun, which one was it?

Has anyone heard of this happening before? Is it a bug with Ant? Meister uses Ant under the covers for some things, but not for the Java compile. We’ve never heard of this problem before. We are, in fact, working with Nick to roll out Meister (and the Java build services used by thousands) to Eclipse at the desktop so mysterious problems like this won’t happen in the future.

The key to success in build management is to have a standard build solution that manages builds in all the stages of an application development lifecycle in a consistent manner. Some of the features that must be considered when developing a standard build solution are as follows:

* Provide a standard, consistent build process from desktops all the way up to production
* Directory structure standards
* Standard build tool
* User and Group Management
* Ability to run inside or outside the IDE
* Handle configuration files for the various stages in a consistent way.
* Runs in an automated fashion without manual intervention
* Provides Bill of Material reports which shows the matching of the run time objects (executables) to the source code (in a version control tool) for audits.
* Provides impact analysis (dependency) reports
* Has the ability to perform pre-processing (such as check out from standard version control tool) and post-processing (such as automated testing and reporting).
* Repeatable
* Portable
* Flexible
* Documentation and Training

By using the standard build solution from the developer desktops all the way up to production, the organization can ensure that the same build process is used in each stage of the lifecycle and is consistent, repeatable and auditable. This would minimize finding build issues at later stages of the lifecycle and also reduce the time it takes to release the code to production.

By incorporating standards and best practices (ITIL, CMMI, SOX…) in the build solution, high quality build management services can be achieved. This facilitates organizations to minimize risk and achieve both high quality and value in IT operations.

Stay tuned for our next topic…