Continuous Integration with CruiseControl is a standard part of the development process here at Shine Technologies. All new projects kick off with a new build server and a CruiseControl install that calls out to the standard Ant build files and jUnit tests. Continuous Integration is a well proven process that both gets a new project up and running quickly and provides long-term support and infrastructure - even for legacy Cobol systems.

At one of our corporate clients, we inherited the maintenance of a large production Cobol-based system. Although we have migrated many of the components to newer Java-based systems, there is still a sizeable component of both screens and batch jobs that we need to support. For its day (mid-1990s), it was a well-architected and designed system that has proved its worth and is still providing solid functionality to the client (how many modern systems currently being deployed do you really think will still be live in 12 years time!?). It uses standard makefiles that call out to the Cobol compiler, producing executables that can then be promoted from the development environment to UAT and then on to production. It's a challenge to keep support and development staff familiar with all the possible technologies that they may encounter on their day-to-day job, and yet still keep them competitively productive.

The following diagram shows the workflow we introduced CruiseControl into:

Note that this article assumes you are working in a Unix-like environment - Mac, Linux, HP-UX etc. In-principle it will work exactly the same on Windows - just not as nicely!

Setting up CruiseControl

The latest releases of CruiseControl come with embedded web-servers, which make it trivially easy to setup and get productive very quickly.

• Download the latest CruiseControl binary version here and unzip into desired running directory
• Read the binary install instructions, but basically get rid of the sample application (edit config.xml removing the Connect 4 section and remove the project under ~/cruisecontrol/projects/connectfour)
• Checkout your desired project manually from the command line. For example, cvs co Shine-Cobol would check out our project "Shine-Cobol" from our CVS server.
  Note that you will need to have your CVSROOT setup. For example in your .profile script you might have:
  
  
• Add a section to config.xml that calls your build script:
  
  
• Stop and Start scripts for CruiseControl can be very handy. You can use the available init.d scripts on the Cruise Control web site here
  Or here is a manual start script :
  
  
• And a stop script which reads the pid file that was created from the start script above.
  
  

CVS Setup

To allow CruiseControl to interact with CVS seamlessly, it is important to setup "password-less" checkouts as CruiseControl will checkout the latest version of code potentially many many times a day. We currently use extssh. Since this is over ssh, and relies on ssh authentication, this is the area that must allow password-less auth (there are many tutorials on the web, google it here).

At a basic level you need to create a certificate, and then copy it to the machine you are trying to connect to.

• ssh-keygen -d -C This e-mail address is being protected from spambots. You need JavaScript enabled to view it This creates a DSA certificate (-d) and add a comment (-C) that this certificate is myself using my iMac at work
• This creates a id_dsa.pub certificate in your .ssh directory
• Now copy it via sftp to the desired server and append it to its .ssh/authorized_keys file, make sure you append and dont overwrite! (cat id_dsa.pub >> authorized_keys)
• Another option on Linux boxes is to use the ssh-copy-id command
  ssh-copy-id -i id_dsa.pub This e-mail address is being protected from spambots. You need JavaScript enabled to view it

Integration with "Make"

Before the days of Ant, many of us had the "pleasure" of using make as our day-to-day build tool, leaving us with fond memories of hours lost fixing failures resulting from some whitespace not being a tab character. That said, at our client site we were fortunate to inherit some solid makefiles that do a good job of building all the needed components needed by the Cobol systems on the mainframe.

So that a full build can become part of the CruiseControl process, we use Ant's exec command to call out to the existing make file. In the example below, we copy all the code checked out from CVS to the necessary Cobol source directory (again this eased integration as there was an existing well-defined Cobol build area that did not fit well with the CVS project containing the code so instead of forcing them to be compatible we simply checkout in one area and then copy over where it needs to go). Then we use exec to call out to the makefile, running it from the directory it needs to be called from \${src.batch}

Promotion Scripts

There are many proprietary solutions for managing software promotions between different development levels. They can be prohibitively expensive, especially if being fitted retrospectively. However, it is perfectly possible to build a robust solution that uses freely available tools. In our case we used Ant, ssh and bash. The following Ant script will deploy to UAT, stopping and starting servers as needed and archiving the old code. Note that it relies on the Ant ssh extension library.

Conclusion

And thats it! You should now have a Continuous Integration build of your old Cobol systems (or any other type of technology that has a command-line build file). Hopefully I've shown that it's relatively straightforward to retrospectively implement newer ideas and tools on older systems without having to make major adjustments or investments. And there are a number of key advantages:

• Lowers the bar for entry for developers who have limited experience of older environments. In our current setup the only general knowledge needed to make Cobol changes is some basic Cobol syntax knowledge which can be made within a checked-out version in Eclipse. This change is then checked in, with the build and deployment then being performed automatically.
• Consistency. It is easier (and thus cheaper to the client) to support a system - even a very large one - if your tools and procedures are the same across all its sub-systems, both old and new. Although Cobol and make require a different skill set, because the build, deployments and promotes use standard Ant files then developers can leverage existing knowledge. The only caveat is that you do need to have an "expert" somewhere in your company if the underlying procedures fall apart, but not on a day-to-day basis.
• Apart from a little time and effort, this is a completely free solution.
• And finally, it limits the "Fear Factor": the next time you ask your 24 year-old developer to maintain a Cobol screen, they won't look at you with quite so much horror!

Web Resources

• Continuous Integration - http://martinfowler.com/articles/continuousIntegration.html
• Cruise Control -http://cruisecontrol.sourceforge.net
• Ant - http://ant.apache.org/
• Make - http://en.wikipedia.org/wiki/Make_(software)
• ssh ant extension - http://www.sshtools.com/showMaverickAntTask.do