Welcome to my blog on topics related to enterprise modernization, collaborative life cycle management, application development for System z and Power Systems, and the latest insights I have gained from our clients experiences in these areas.
Today's topic is the value of automating builds for mutli-platform applications. This topic was on the minds of a number of customers at our recent Information on Demand Conference. I thought it would be useful to capture some of the discussion and insights here.
The key to automating builds across platforms is to have a common infrastructure that can be used to control the builds on the appropriate platforms by coordinating the work being done among the teams. Rational Team Concert (RTC) is designed to provide such an environment allowing your teams, working on the different platforms, to work together on a common plan in a coordinated development process.
Lets work through an example to show how this might be done. We will use a simple mortgage program. This program has a CICS back end that does the actual mortgage calculations which are backed by VSAM data. This program also has a web front end that is hosted in WebSphere Application Server. This combined application has multiple teams working on it. For this example, we will focus on the front end Java and the back end COBOL CICS development teams. Within RTC, there is a project created to handle the Mortgage application enhancements and maintenance. Within the project, each development team is defined as it's own team, with it's own streams and builds that are managed within the context of the project. The project can also have shared elements. These are usually integration elements such as interface definitions. Each team can work on their own changes while also addressing the shared components such as between the web service interface definitions used by the front end user interfaces to access to the back end functions. Each team has their own build definitions so automation can be used to build and test parts independently. That same automation capability with some project level definitions can be used to build combined front and back end executables, as desired, for team level testing.
The nature of today's composite applications often entails multi-platform builds that can be far more complex than this simple scenario where the teams can share the required components, but can build separately. When significant coordination needs to happen as part of the build process, such as building part of an application, delivering some changes then causing other platform builds, a more sophisticated automation engine may be required. Build Forge can be used to provide this high level of automation and coordination within RTC context.
Recognizing that RTC may not be in use across all development groups, let's look at a second example where the front end team is using RTC and the COBOL CICS development group is using an alternative SCM and build infrastructure. In this case, the teams can come together in RTC to do their planning and collaboration. Further, RTC builds could be used to kick off the alternative SCM builds to provide a single coordination context, while still using an existing alternative environment.
RTC enables the teams to work together, sharing information about the status of the project as well a using the RTC automation facilities to coordinate builds across diverse environments, some part of RTC and some not.