Importance of Version Control in Cloud Development

A few years ago, I was asked to deploy vCAC (as it was known then). Soon after I found myself part of a team dedicated to creating a new Service Catalog for an SDDC based Private Cloud offering. It was a huge learning curve for me and I was soon immersed in a world of Cloud development with decisions to make based on these new VMware Cloud tools. The one thing that I did learn very quickly was the importance of version control. Coming from an infrastructure background, this was alien to me but it soon became one of the most critical things I learnt about successfully developing a Private Cloud and more importantly – maintaining it!

At the heart of our Service Catalog was vRealize Orchestrator and as requirements for automated Catalog items grew, so did the team. This caused a lot of issues, with many developers working simultaneously on the same product and as a result changes to the same Workflows occurred and relevant changes lost. It soon became apparent we where lacking a sensible way to ensure our final packages was bug free and not overwritten unintentionally. Natively in vRO we can export a package containing Workflows, Actions, Configuration Files etc, but this is not in an ideal format to efficiently review or track changes. It was becoming impossible to keep tabs on what was happening.

Continue reading

Completion Request Details in vRO7.x

As some of you will be aware, vRA6 will be end of life support by the end of 2017 and as a result i was tasked with deploying a POC for vRA / vRO 7.3 in order to check if our current vRO code was compatible. I expected to see some challenges as we are heavily reliant on vRO for our Service Catalog, however one specific issue I did not expect caught me out.

As part of our Private Cloud offering, we use vRO to request a catalog item rather than vRA. The overall workflow also contains many post request actions such as deploying agents, resetting default passwords etc. All of these rely on the successful deployment passing us the hostname after the catalog request completes. After setting up the POC and running a test deployment I  noticed that although the request was successful, the overall Workflow was failing. Looking deeper I saw some differences in the completion details of vRA7.

In vRA6, we used to get the following, where “tyler-prefix04” is the hostname of the newly created VM:

Continue reading