Blogs about Jazz

Blogs > Jazz Team Blog >

The role of Rational Asset Manager as a DevOps broker

Gone are the days when development teams develop monolithic applications completely from scratch. Reusing open source components, frameworks, and services is quite usual. It is also common that a single application is composed with packages that are delivered by different teams.  The deployment of these applications has to take into account which package level to use for a particular deployment.  These teams (in-house or sub-contractor) are often driven by diverse development processes and iteration schedules.

It is hard to track or make sense which components are used in a particular team’s build, or which package levels should be deployed across various deployment environments (development, test, and production). Source control systems are not designed to manage and share these packages, which are typically binary. This is because they are not geared to manage the version explosion of delivered packages, nor do they simplify usage tracking for these packages across diverse consumer projects and deployment environments. Software libraries, sometime referred to as repositories, are more suitable in brokering the consumption of these development deliveries.  They provide facilities to search and link to the right package (and its dependencies), and provide the means to collaborate around these packages with notifications, discussion, and optional links for engaging the package development team through a change request.

Library usage in development

During development, developers typically deploy their application to local/workgroup level environments.  These environments are often quite different from the production environments the applications are going to end up in.  Applications usually pass through a sequence of deployment environments on the way to production (development, test, acceptance, and production).  The deployment process of these applications into these environments requires special handling. This is because each environment is often under different compliance rules and dependent on specific components, configuration, and topology.   These artifacts are not are not part of the bill of materials (BOM) that is delivered by the development teams.  This results in a slow, manual progression into production.

DevOps” is an emerging set of principles that come as a response to the realization of the disconnect between development teams and operations teams and their processes. The essence of the DevOps approach is as following:

• Build a symbiotic relationship between development and operation
• Think about applications not projects
• Use automation in place of documentation (and more automation)
• Create a self-service infrastructure for teams
• Decrease the skill level required to deploy platforms
• Reduce maintenance costs by keeping systems “young”
• Deploy more frequently
• Replace instead of update

The idea is that the combination of frequent and automated deployments will lead these activities to be as reliable as the “recompile” process today. Frequent from scratch deployments will ensure that what’s deployed and how it is configured is well understood,  re-creatable, and can be managed just like software change is managed today. This approach is a revolution from what is typically customary today, where a manual process for migrations, updates, or patches is delegated across various roles. It may take some time for many applications and environments to adapt to more standard configurations/deployment processes. There are many applications and environments today where the DevOps theme can bring about huge efficiencies in reducing the time it take to deliver application changes.

A formal software library is the basis from which one can drive re-creatable automation across the various deployment environments.  A library can help keep these environments deployed with the same configuration/automation artifacts (runtime as well as data). Libraries can also help with tracking of the BOM that was used across the various deployment automation activities.

There are many artifact-specific repositories out there (like OBR for OSGi bundles, Yellowdog Updater for RPM packages, Eclipse p2 for Eclipse plugins etc.) that are used by various automation/install processes.  Rational Asset Manager 7.5.1 (RAM) is an enterprise library that can catalog and manage any type of application package. RAM is well integrated with development tools and automation frameworks. RAM is already being used as a DML for approved deliverables. But, it can also be used for auditing and managing automation of BOM usage across various deployment environments. This is key because it will facilitate consistency and reuse of proven artifacts (packages, scripts, configurations, patterns etc.).

Doing more of the same increases the probabilities of success. Driving reuse with a library is the basis for that success.

Dr. Gili Mendel
Senior Technical Staff Member, Rational Asset Manager