Cloud Lifecycle Management for CI/CD DevOps – Part II

In part-I, we described the challenges in a typical CI/CD environment.  In this blog, we will show how BMC Cloud Lifecycle Management (CLM) can be used to address these challenges.


By using CLM along with Jenkins and a few other automated testing tools and scripts, we were able to address the above challenges and provide a complete fully automated devops pipeline that resulted in huge developer time savings, sanitized consistent environments and deployment automation.  Let us see how CLM was used to achieve the devops pipeline for CLM leading to a high ROI far beyond our expectations in many other areas shown below.

As seen below in Figure 2, as soon as build is successful, automated testing of the CLM application takes place that runs thousands of tests by provisioning test infrastructures using CLM.  After successful tests, the hardened CLM application is automatically converted into a “service offering” in a CLM for that specific build.  The CLM service catalog is updated with this new service offering and made available to the development and test teams for downstream activities such as provisioning of the latest CLM application stack for their individual testing.  We have 100’s of developers each day creating CLM application stacks (‘application environments’) as shown below.


Figure 2. CLM is used to provision hundreds of CLM stacks each day

CLM Service Catalog

Figure 3 below shows an example service catalog that is used by our engineering team for on-demand deployment of CLM application stacks for current and older releases.  Offering deployable application environments for CLM daily and prior releases have resulted in high developer productivity.


Figure 3. Service catalog of CLM service offerings

Converting CLM deployable artifacts into service offerings

Once the CLM has been built and tested through the DevOps cycle, the CLM deployable artifacts are automatically converted into service offerings that developers can request through service catalog as shown above.  This consists of a number of steps that are automated:

  1. A virtual machine is provisioned through vCenter
  2. CLM deployable artifact is next installed on it
  3. Sanity tests are executed
  4. After this, a template is created using vCenter CLI
  5. Finally, CLM SDK/API calls are used to update or create new service offerings based on the newly created template that reflects the new version of the CLM application

Day 2: CLM application – Take environment snapshot

A developer who has provisioned their own CLM application stack can take snapshots of the complete stack using a day 2 action, such as “TakeVMSnapshot”.  This is shown in the figure 4 below and can be useful in saving application and machine state for debugging during the dev cycle or reverting back to a consistent state.


Figure 4. Taking a snapshot of developer’s CLM environment

This new custom action was implemented by creating a BMC Atrium Orchestrator (AO) workflow that implements the action to take a snapshot, configuring the Callout Provider, and then using API calls to import the BMC Atrium Orchestrator workflow to BMC Cloud Lifecycle Management.  The high level steps to do this are given below:

  • Step 1: Define and write the AO workflow.  This workflow accepts the context information for the virtual machine identifier (additionalInfo parameter holds this information about ComputeContainer, VirtualGuest, User, Service Offering Instance), calls nsh script that connects to BSA which then invokes snashot on vCenter.  Alternatively, AO workflow can also directly use the vCenter adaptor to directly execute a snapshot call to vCenter.
  • Step 2: Configure Callout provider in providers.json
  • Step 3: Use REST API to import AO workflows
  • Step 4: Customize parameters in Reference Action Catalog.  In our case, we added these parameters:  Set optional, Set encrypted, Set parameter order and Set end user input required
  • Step 5: Use REST API to refresh Action Catalog
  • Step 6: Put i18n labels

See user documentation for more information on creating custom server actions:

Day 2: CLM application – Update a component

In addition to taking day 2 actions for taking snapshots of the CLM application stack, a developer can also update a specific component within the application stack by either pushing code directly to the stack or using another day 2 action such as ‘Update Component on CLM Application’.  This can help in developer level integration testing of their component and testing it against a complete consistent CLM application environment.


The benefits for several of the stages in our devops pipeline are summarized below:

Stage Product used for automation Metrics Savings
CI Builds Jenkins 5000 builds/release in 6 months
Automated deployment CLM Hourly, Nightly, Daily and Weekly deployments done using CLM!
Automated testing Silk and Selenium 1000’s of tests run each day automatically
Environment infrastructure provisioning and deprovisioning CLM 30 per day No static infrastructure – savings $$$
Day 2 actions – snapshots CLM Hundreds each day by developers
Service catalog and Portal 20 service offerings, 200 users and 150 SOIs Productivity benefits with consistent build and deploy environments – developers can deploy environments in one-click
CLM Application Lifecycle management CLM Developers and QA can manage lifecycle of their private CLM application stacks by starting, stopping, updating continuously as needed. Consistent simplified UI and environment to provide common dev tasks results in developer savings.
Automated reclamation CLM Unused CLM stacks are automatically reclaimed $$$ savings
Testing and Application infrastructure on any target – on-prem and in cloud CLM CLM allows to provision application environments to on-premise as well as AWS and other cloud infrastructures $$$ savings and flexibility
Maintenance of older releases CLM Service offerings for prior releases also available with pre-baked data Huge savings as prior releases can be deployed in one click through service offerings


In addition to CLM application stack as service offerings for our developer community, we are also offering many other container and PaaS stacks for developers to do innovations and experimentations.  For example, we have made available “Docker Hosts” as a service offering in our service catalog that allows any developer to request a Docker Host in a few minutes to start using containers.  We also plan to make PaaS environments and other middleware application environments available to developers to experiment with new technologies and continue with innovations.  Finally, during our conferences, we have used CLM to manage and run our hands-on labs to provision hundreds of CLM application environments on AWS cloud for training at scale.


At BMC, we take drinking our own champagne very seriously.  We continuously build, test and deploy CLM using CLM.  This has resulted in huge improvements in product quality, speed and agility in providing faster releases to the development team and infrastructure savings.  We believe that CLM can be used very effectively in managing any application DevOps pipeline in three critical areas:  a) Infrastructure as code b) Dynamic infrastructure can result in cost savings such as test environment creation and decommissioning, and c) Providing service offerings to developers for machine, PaaS, middleware and application environments that will increase developer agility and happiness.