A solution should enable production deployment teams to:

The solution must allow development teams to:

The ideal solution will consist of a software configuration management/version control system; a change management/process and workflow system; and a reliable, repeatable build process. The software configuration management (SCM) system should be a secure, client/server, cross-platform application. It must seamlessly integrate with the WebSphere Studio family of products. It must provide a 100% reliable method of re-creating a past version; simple labeling is too prone to errors.

A change management application should allow for the definition of a variety of flexible development processes and be tightly integrated with SCM systems on distributed iSeries and zSeries platforms. A robust command line and event trigger mechanism should allow the change management system to trigger and control external actions in the development process. The build application should ensure that every member of the team builds the application the same way every time. Unproductive Ant XML scripting should be reduced.

Let's review a real-world scenario. In this case we'll be referring to specific functionality found in MKS Source Integrity Enterprise Edition, an enterprise SCM solution. Baselining in Source Integrity Enterprise is achieved by an action called checkpointing. The checkpoints are versioned, meaning that an earlier baseline can never be corrupted. Corruption is possible with solutions that rely on labeling, however, once a project has been checkpointed, new development can carry on, with full confidence that any previous release can be re-created for maintenance work.

Figure 1 shows a graphical view of a member history that a developer can use to visualize the status and history of a source file, and also to perform actions such as merge on it. This view is also available for project history.

 

MKS provides a Ready for WebSphere Certified version control plug-in for the WebSphere family of products. A key aspect of this integration is its unique ability to dynamically update file status decorators that provide WebSphere developers with real-time status updates. This reduces the amount of code merging required and increases the visibility of project activities, allowing developers to make informed decisions. Conflict avoidance versus conflict resolution results in superior-quality applications and increased developer productivity.

Figure 2 shows the file status indicators and the file decorators added by the MKS Source Integrity Enterprise Edition plug-in. They are updated in real time without any user action or input.

 

MKS Integrity Manager is a flexible, configurable development process and workflow engine. It is tightly integrated with MKS Source Integrity Enterprise for distributed platforms and MKS Implementer for iSeries, and can be integrated with zSeries-based SCM systems. This provides management with a single Web-based change management system to oversee development and to link source code changes with issues across all platforms. MKS has introduced a Build & Deploy module as part of Integrity Manager. This module provides the production deployment staff with the ability to automate, control, and report on all build and deploy activities.

Openmake from Catalyst Systems is an award-winning application build process automation tool. It provides the ability for any developer to do full or incremental builds reliably on any machine the same way every time, while eliminating the need for manual makefile or Ant XML scripting. Upon completion of a build, Openmake creates a Bill of Materials (BOM). This BOM includes information on every component that went into the EAR file.

The following scenario features a stand-alone J2EE application developed with WebSphere Studio Application Developer 5.0 and deployed to WebSphere Application Server 5.0 running on AIX 5.2 Version 1.0 of the application contains 1,200 Java source files and has gone through complete systems integration and user acceptance testing; it has been in production for a month. To ensure version 1.0 can always be re-created, it was checkpointed with Source Integrity Enterprise. It was built using Openmake and moved into production using the Integrity Manager's Build & Deploy module. After the application was built by Openmake, both the EAR file and the BOM were added to a Source Integrity Enterprise project for later use. Since that time, significant development has been done, working toward version 1.1. The work has resulted in 300 new files and changes to 50 existing files.

A serious bug has just been reported and must be fixed immediately. Investigation of the problem has been completed and development work assigned. Issues are created in Integrity Manager and assigned to three developers. It is clear from the Build & Deploy request that the production version (1.0) refers to Checkpoint 1.0. This information is provided to the developer in the issue. Each developer will work on a variant project, based on Checkpoint 1.0. In this way, none of the changes made since the release of 1.0 will be in their WebSphere project workspace.

An administrative option for this environment has been set that requires developers to add all work they do to a Change Package. This Change Package must be associated with an issue that has been assigned to them in Integrity Manger. As they work on their changes, the dynamically updating status indicators will clearly show the effect other developers may have. They can choose to bring in the other changes to do their unit testing. Once complete, they close their Change Package and mark their issue as complete. Once all developers have completed their unit testing and have closed their change packages, it's time to move to the next stage of the process.

A Build & Deploy request will now be created in Integrity Manager to move the work through to production. The first action is to associate with the new Build & Deploy request all of the issues where work was attached. All of the changes will be automatically applied to Checkpoint 1.0. Once applied, the request will be moved to a ready-to-build state, which triggers Openmake to perform the build. The new EAR file and BOM will be added to a Source Integrity Enterprise project and a new checkpoint created.

In this view we see a Build & Deploy request. The State indicates the EAR file is ready to deploy and the "Source Code to Build" field shows the Change Packages from the related issues have been applied to the appropriate development path.

 

The Build & Deploy request will now call the WebSphere Application Server command line to install and deploy the EAR file on the designated systems integration test server. The QA technician will receive notification that work is assigned and ready for testing. Keep in mind there was a detailed BOM created by Openmake for both the production version of the EAR file and the current EAR file just deployed for testing. As part of the process, the technician can use Source Integrity Enterprise to differentiate between these two BOMs to be certain only the desired changes from the three developers were introduced. They can now QA-test those changes with confidence.

Upon successful testing, the EAR file can be deployed for another test phase or be promoted directly into production. This process is flexible and can be set up to meet the team's specific business needs.

Now that the issue is fixed in production, another important step is to ensure it is not re-introduced when version 1.1 goes live. The same Change Packages created to fix the problem in 1.0 can be seamlessly applied to the version 1.1 line of development to ensure this does not happen.

Conclusion
I have discussed how a tightly integrated SCM and change management system, combined with a mature build process, can address many of the complex issues facing today's enterprise Java development teams. There is a system that can provide the process and management control needed without inhibiting developers' creative talents.

In Part 2 of this series, Adam Terrenzio of MKS Inc. will discuss ways SCM plug-ins can help developers with day-to-day activities in his article, titled "Teamwork in WebSphere Studio."