Aldon Introduces Version Control to Build and Release Management

May 5, 2009 Dan Burger

People are not robots (tell that to your manager) and application development teams are going to use whatever versioning tool they want. Distributed development environments have made sure of that. It’s a corresponding truth that application build and release processes are bit more complicated, but you’ve probably already noticed that. So have the product designers at Aldon, an application lifecycle management software company with a long history as an IBM i vendor.

Aldon, last week at the COMMON 2009 Annual Meeting and Exposition, introduced the availability of a new Build Release Management (BRM) product that allows development teams using a variety of versioning tools to all participate in single application lifecycle process that brings change management rules to distributed environments. Among the versioning tools that come under the management of BRM are Subversion, CVS, Perforce, and Microsoft‘s Visual SourceSafe and Team Foundation.

This pretty much covers the most popular tools, and because almost all version control systems are built on similar architecture, Aldon has most of the bases covered, including the capability to move third-party software packages through the application lifecycle management process. One exception to that is the IBM Lotus development environment, which is outside of Aldon’s reach.

Application development is not the Wild West. Whether there are multiple environments or not, control is a good thing. And if you are paying heed to regulatory compliance mandates, control is absolutely necessary.

Developers in IBM i environments are usually–but not always–familiar with controlled application development. When multiple development environments exist within the same organizations, it can be difficult to get them all working together with the same goals and objectives. Developers in mixed environments tend to approach things differently, but there are some similarities.

The majority of IT shops have some sort of version control tool or even multiple tools. While version control tools give users the capability to manage software versioning through check-outs and check-ins, they are not designed to assist with the software build-and-release process, nor do they track code and changes made to it.

Most importantly, Aldon’s BRM allows developers to do all their checkouts, check-ins, branching, tagging, and other version control functions with their preferred version control tool. After a build package is completed, it is automatically passed to the BRM system. At that point, it enters a pre-defined software development lifecycle that includes functions such as automated processes, workflows, notifications, and approvals.

The BRM solution tracks, manages, and deploys the application through automated workflows and best practices. At any given time, users can see, capture, promote, and report on changes in the software development cycle.

Throughout the process, changes are tracked and compliance reports are recorded.

Rather than relying on scripts or manual procedures to create compliant move-to-production processes, the Aldon BRM solution provides point-and-click setup function for creating and maintaining approved workflows. After the workflows are defined, the system enforces and automates them.

Development work typically involves simultaneously working on multiple applications and multiple releases of applications. Getting a handle on the in-progress modifications and various versions and providing the automation to do this is one of the key benefits of a build release management product. Additional benefits include a full view of build packages and all files within the package as it moves across the lifecycle; the capability to maintain package integrity and automate workflow; providing developers with a history of changes so that if the package goes back into development for more work the developers have reference points for what went wrong along the way; avoiding the deployment of packages until potential problems have been solved; and automatic gathering, packaging, distribution, and installation of application components to all target platforms.

Aldon claims its BRM product aids in the coordination of development and operations teams, reduces the costs associated with promoting new code to production, and averts potential risks before pushing code into production.

Build release management is entwined with application change management, and both fit under the umbrella of application lifecycle management. BRM, at its core, takes any application package that is built outside of the ALM and brings it inside by supporting an organizational framework and specific skill requirements through quality control procedures affecting IT department processes. This is accomplished primarily through monitoring workflow and the quality of service.

Although the IBM AS/400 (IBM i, System i, iSeries) has a reputation as a solid, self-contained environment known for providing programmers and administrators with plenty of automation, IT management is not limited to a single platform in 99.9 percent of organizations. And version control is not going away anytime soon. If anything, files are becoming more complex and application integration is having a greater impact on multiple platforms. It will continue to be necessary for IBM i shops to measure and monitor the impacts of non-IBM i platforms and team members.

Aldon’s BRM product is a component of its lifecycle management software. Customers on current maintenance contracts get the new functionality for free.

For additional information, check out this Aldon BRM Web site where you’ll find white papers such as “Strategies for Effective Change Management” and “Going Beyond Version Control,” and an e-book chapter download titled “When Build Release Management Meets Version Control.”