Your Resource for All Things Apps, Ops, and Infrastructure

Cloud Management Tools: Using vRealize Code Stream to Facilitate CI/CD

Part of the AHEAD Cloud Delivery Platform (cloud management and automation component) focuses on DevOps and modern software development methodologies. We understand that there is no point in building the world’s greatest cloud if no one uses it. As part of our journey, we’ve begun looking at tools that enable DevOps practices, namely Continuous Integration and Continuous Delivery (CI/CD). One of the classes of tools that helps facilitate CI/CD is called Application Release Automation tools, and I’d like to focus on one example in this post: vRealize Code Stream.

Example Application and Code Control

Curless_blog_CICD_1.pngAs we showcase various DevOps practices and tools, we needed a basic application to illustrate the process and to build upon. We chose to create a simple “Track My Bag” application that fits the theme of our factitious company, AHEAD Aviation. Using this app, travelers can locate and find the status of their baggage by looking up their name or by scanning the tag they receive upon checking their bag.

This simple application was built in HTML and committed to our GitHub code repository.  In fact, this is the first step in our Continuous Integration process: leveraging GitHub to maintain our code across developers and versions. Everything is checked into the main branch so that we can always build a production copy.

The idea behind Continuous Delivery takes this a step further by automating the testing and build process so that an updated copy is always ready to move into production (and therefore, be seen by users). As a developer checks code in GitHub, this triggers a build job on our Jenkins server. The process is not manual or based on a time interval, but triggered by an actual commit. It can happen as many times in a day as is necessary.


vRealize Code Stream

vRealize Code Stream (vRCS) is the tool used to automate the various pipeline stages of the development process (i.e. Dev, Test, QA, UAT, Prod, etc.). It has an easy-to-use interface built into vRealize Automation. To use, one would simply enter their vRealize Code Stream license, enable the proper user rights, and the Code Stream tabs will appear upon next login. Release automation engineers can create new pipelines for various projects, creating as many stages within the pipeline as they wish.

In addition to stages, Code Stream also has gates between the pipeline stages; a gate can be successful completion of testing criteria or an approval process. If any test fails, the pipeline is automatically shut down and alerts are sent.



As a developer or QA manager kicks off a build pipeline, we enter the Development stage. In this stage, we get our first look at the separation of duties between development automation and infrastructure automation. In this example, we use infrastructure automation to deploy development VMs on AWS. vRCS calls a vRA blueprint to deploy to AWS, which in turn, defines addressing, creates a CMDB entry, and kicks off a Puppet run to deploy our Apache Web Server to the new Dev VMs.


vRCS deploys our current application build, and invokes a Selenium test to verify functionality.  As we move from the Development stage into the Quality Assurance stage, we use a gate to ensure 100% passing from our Selenium test.

Quality Assurance

In the Quality Assurance (QA) phase, we program vRealize Code Stream to do a number of interesting things for us. The first step is to call vRealize Automation workflows to terminate development instances in AWS (when we’ve finished testing on them and don’t need to continue paying for these resources). The Dev VMs exist in the moment for exactly as long as they need to. The vRA ‘destroy operation’ illustrates an important cleanup phase in the cloud automation lifecycle.

The vRA workflow also calls plumbing workflows to do things like clean up DNS, clean up Puppet, mark CMDB objects as deleted in ServiceNow, etc. It’s about more than simply deleting a VM; we want to clean up after ourselves and reverse the entire deployment process.


vRCS continues the QA phase by again calling vRA blueprints, this time to deploy VMs into our on-premises private cloud. This endpoint is closer to where we run production and allows us to test more comprehensively. Once our environment is prepared, our code is once again deployed, and this time, the gate to move into production involves vRCS creating a request in ServiceNow for a QA manager to approve. At this point, the idea is that the QA environment is available for advanced testing and lives until the QA manager signs off on the build and moves it into production.


At the end of the release pipeline, we move into production. In this stage, vRCS first checks to make sure the build has been approved. Once it’s been approved, it again cleans up the environment by calling upon vRA and vRO to delete QA VMs and objects. By now, you will notice plenty of workflows being reused in both the build and tear down phases of each stage. This is by design and saves us a lot of work.


In this stage, we once again take the approach that VMs themselves are not important.  Instead of overwriting our old code on the production servers, we call on vRA/vRO workflows to build new VMs, grab their configuration from Puppet, and update the CMDB. The new code build is loaded into Artifactory as an artifact, where it is also assigned a property of “approved” by the QA manager. This means that if an artifact is lacking the “approved” stamp, it cannot be accidentally promoted to production.

The production site is really tied not to VMs, but to a VMware NSX Load Balancer VIP. The workflows update the Load Balancer pool with the new VMs (which have the new build), and also remove the old VMs so they can be destroyed. This occurs without interruption to the user as the load balancer maintains the application continuity.

At this point, our new code is in production! Aside from the QA manager approval in this example, the entire flow is automated. Plus, none of the artifacts created along the way exist for longer than they are needed, which dramatically cuts down on complexity and resource waste.

This was a very simple example that demonstrates the power of Application Release Automation using vRealize Code Stream. Stay tuned for future posts that explore other DevOps tools as we continue to learn and evolve. If you’re interested in learning more about CI/CD principles or DevOps tools, please schedule a time to meet with our experts in the AHEAD Lab and Briefing Center today!

AHEAD Lab and Briefing Center

Watch On-Demand Sessions from our Spring Summit, Automation @Scale!

Subscribe to the AHEAD i/o Newsletter