No one can argue that today's business environment demands a high level of prudence and control. The risks are too great to be careless in any aspect of a business. The software delivery process is no exception. Since software typically lies at the heart of most core business processes, software delivery often attracts an even higher level of scrutiny than most other business processes.

Over the past few decades, software delivery organizations have become increasingly proficient at managing the source code and other development artifacts that they produce. Many have adopted sophisticated version control and change management systems such as IBM® Rational® ClearCase® and IBM Rational ClearQuest® to gain control over the numerous change requests and code versions that exist in the context of their projects. Some have also automated their build processes with products like IBM Rational Build Forge® that produce detailed bills-of-material to document every version of every file that is included in each build.

Similar strides have been made within IT operations. The Information Technology Infrastructure Library (ITIL®) has gained broad support, and many IT operations organizations have turned to tools like IBM Tivoli® Change and Configuration Management Database to gain control over changes to the numerous applications, components, and services that are deployed throughout the enterprise.

Where many IT organizations still struggle, however, is at the boundary between development and operations. Builds are typically pulled out of development source code repositories and posted to FTP sites or file shares without any accompanying metadata. Even the version number of the build is encoded within the file name or some folder structure. When operations receives a new build to deploy, they register the change in their configuration management database (CMDB) but have little visibility into its audit trail, bill-of-materials, or quality logs. Despite having good development and operations processes in place, IT organizations who lack true end-to-end governance still struggle in this critical area.

This article describes how a software delivery organization can gain control and establish proper governance over the software that it produces or purchases and then deploys. It describes the products that participate in the solution, the integrations between those products, and the usage scenarios that demonstrate the value of the solution.

The development/operations disconnect

The consequences of this disconnect between development and operations can be serious. When the operations group inadvertently deploys a version of software that has not been properly tested or reviewed, the business may suffer from a resulting service outage or security breach. When they deploy software that includes unauthorized or unlicensed components, the business may be exposed to financial and/or legal risk.¹

Consider a deployment team that receives a new software build for an application that handles credit card information. The Payment Card Industry Data Security Standard (PCI DSS) requires that all applications that handle credit card information must be reviewed for security vulnerabilities.² Even if previous versions of the application have been reviewed, how can the deployment team be sure that the new version they are about to deploy will not expose the business to a security vulnerability hidden in the new functionality? Before they deploy the new version into production, the deployment team needs to be able to determine that it has been scanned, that the scan has been reviewed, and that an authorized release manager has verified that no significant vulnerabilities were detected. Without a well-defined, well-governed handoff, this assurance cannot be guaranteed.

Or consider a development team that downloads a third-party component from the Internet and includes it as part of their application. If the application gets deployed without satisfying the conditions of the licensing agreement, the business is now in violation of the license agreement and is subject to legal penalties.

In addition to the more severe consequences that can occur as a result of a disjointed handoff between development and operations, prolonged communication cycles can also result in delayed deployments and lost business opportunities. Poor communication can also delay troubleshooting, which can lead to lengthy system outages and user dissatisfaction.

The solution described in this paper leverages the collaboration and governance capabilities of IBM Rational Asset Manager and Tivoli Change and Configuration Management Database to ensure that a more efficient, reliable handoff occurs between development and operations. It also addresses the needs of release managers who are responsible for determining whether a release should be deployed or not.

Back to top

What is a Definitive Software Library?

The term Definitive Software Library, or DSL, comes from the ITIL V2 guidelines and refers to a central repository for software images and related information. A DSL may also be referred to as a Definitive Media Library, or DML, per ITIL v3. It is the library from which the definitive authorized version of software, software documentation, licensing information, and other relevant information is referenced. In the IT environment, it is the location from which software middleware, application images, and provisioning scripts are acquired for deployment. In development, it is where developers find approved components (open source components, approved services, or internal components) to develop against; and, more importantly, ensure that these are the components that applications are built and tested against. This promotes reuse and consistency across a development organization and enables the governance needed to achieve greater predictability.

Back to top

Establishing a Definitive Software Library

IBM recommends a federated approach to establishing a DSL that effectively bridges the gap and facilitates effective collaboration between development and operations. On the development side, Rational Asset Manager manages approved master copies of each software image. These images are maintained separate from development and test file store areas as recommended by ITIL. To manage and accelerate the approval process, Rational Asset Manager consolidates information relevant to making an approval decision, linking the build itself to quality logs and vulnerability scan results. When teams need to understand the details related to how software should be deployed, they can navigate from the image to related assets, such as provisioning scripts, whitepapers, tutorials, etc.; or they can collaborate using forums that are linked to the images. To keep all interested stakeholders apprised of changes, Rational Asset Manager provides a subscription capability that sends notifications through e-mail or RSS/Atom feeds when changes are made.

On the operations side, Tivoli Change and Configuration Management Database keeps track of where the software has been deployed within the IT environment and the details related to the deployment, such as changes, performance against Service Level Agreements (SLAs), or license usage. When used together, Rational Asset Manager and Tivoli Change and Configuration Management Database form the bridge that keeps development and operations in sync.

As new software images are approved for release in Rational Asset Manager, they become available for import into the Change and Configuration Management Database (CCMDB) as configuration items (CIs). Links are maintained between the software image assets in Rational Asset Manager and the software image CIs in the CCMDB, allowing in-context navigation in either direction.

When a development team needs to understand how a piece of software is being used within the business, they can easily navigate from the development side to the operations side and review production-level statistics. When operations experiences a problem with software in production, they can quickly determine from development who owns the software and even the details of which tests were run prior to release. Most importantly, operations can ensure that the images that they are deploying into production have been properly reviewed and approved before they move them to production, reducing risk and increasing stability within the business. Figure 1 illustrates how the DSL supports this high degree of traceability.

Figure 1: A federated approach to establishing a Definitive Software Library

Figure 2 illustrates how development and operations can leverage different views on software assets through the DSL.

Figure 2: Development versus operational view of assets

Figure 3: Link from software images in Rational Asset Manager to configuration item references in the CCMDB

For information on how to set up the integration between Rational Asset Manager and Tivoli Change and Configuration Management Database, refer to the demonstration posted at: http://download.boulder.ibm.com/ibmdl/pub/software/dw/demos/RAMCCMDBConfig/ram71ccmdbconfig_viewlet_swf.html?S_TACT=105AGY82&S_CMP=GENSITE

For information on how to use the integration between Rational Asset Manager and Tivoli Change and Configuration Manager, refer to the demonstration posted at: http://download.boulder.ibm.com/ibmdl/pub/software/dw/demos/RAMCCMDBIntegration/ram71ccmdbintegration_viewlet_swf.html?S_TACT=105AGY50&S_CMP=DEMOS

Back to top

Populating a Definitive Software Library

Once a DSL has been established, it needs to be populated with software images. While this could be done manually, a more efficient method is to take advantage of the automation offered by Rational Build Forge and incorporate both the posting of the builds and the linking of the builds with compliance and quality reviews into the build and release process.

Build Forge utilizes an adaptive framework to help development teams standardize and automate repetitive tasks. It centralizes, automates, and documents the entire build and release process -- eliminating manual tasks and human handoffs that lead to build errors, schedule slips, and divisive finger-pointing. It integrates with version control, test, and defect tracking systems to provide complete documentation and traceability to answer critical questions such as "What changed from the previous version?", "Who made changes and why?", and, "What defects were resolved?" for each release. Figure 4 shows the steps in a build/release process as automated by Build Forge.

Figure 4: Build Forge manages the steps of the build and release process

Build Forge leverages a set of Ant scripts that ship with Rational Asset Manager and call the Rational Asset Manager API. These scripts can be used to download dependent components from the Rational Asset Manager repository (to ensure that only approved components are used in the build) and post milestone or candidate builds back to Rational Asset Manager where they can be reviewed and approved by the release manager. When Build Forge posts an image to Rational Asset Manager, it provides the proper categorization and sets the dependencies to related components.

Figure 5 shows an Ant script that has been wired into a build and release process in Build Forge. The lines that begin with <ram: denote steps where the Ant scripts have been utilized.

Figure 5: Sample Ant script calling the Rational Asset Manager API to post a new build
Click to enlarge

Additional steps can be added to the build and release process in Build Forge to scan the build for security vulnerabilities and verify code quality. IBM Rational AppScan Build Edition and IBM Rational Software Analyzer provide APIs similar to those found in Rational Asset Manager which can be used to execute these steps.

After the scan is complete, Build Forge calls to Rational Asset Manager once more, only this time it establishes links from the build asset previously posted to Rational Asset Manager to the scan results produced by Rational Appscan and Rational Software Analyzer. This creates a comprehensive view of the build asset which can be reviewed by the release manager and, if approved, deployed by operations with assurance that the images have been properly reviewed and approved before they are moved to production. Figure 6 illustrates how the DSL is populated using the products and procedures just described.

Figure 6: Populating a DSL with new software builds

Another method of populating a DSL is to take advantage of the integration between IBM Rational Asset Analyzer and Rational Asset Manager. The details of this integration will be discussed in a follow-on paper that focuses on the role that the DSL plays in supporting impact analysis.

Back to top

Conclusion

Establishing and populating a Definitive Software Library is an important step toward improving the effectiveness of the collaboration between development and operations. By collaborating more effectively around the software to be deployed, both development and operations benefit from the assurance that the software that gets deployed is secure, of sufficient quality, and approved for release. With fewer mistakes in the build and release handoff, the business benefits by reducing its risk, minimizing its downtime, and improving its operational efficiency.

Back to top

Notes

1. http://www.itil-itsm-world.com/itil-5.htm
2. https://www.pcisecuritystandards.org/pdfs/navigating_pci_dss_v1-1.pdf

Resources

Learn

• Demonstration:Setting up the integration between Rational Asset Manager and Tivoli Change and Configuration Management Database
  
  
• Demonstration: Using the integration between Rational Asset Manager and Tivoli Change and Configuration Manager
  
  

Discuss

• Participate in the discussion forum.
  
  
• A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
  
  
• Global Rational User Group Community
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• The development/operations disconnect
• What is a Definitive Software Library?
• Establishing a Definitive Software Library
• Populating a Definitive Software Library
• Conclusion
• Notes
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Rational Asset Manager
• Demo: Automating the delivery of reliable software
• Webcast: Reduce cost and speed time to market with Quality Management and Asset Management
• Briefing: Jazz and Rational Team Concert
• Buy: Rational Asset Manager

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers