One benefit of moving to Infrastructure as Code is that you can use version control to gain visibility into changes in your definition. When you are working with a simple blueprint construct, it is easy to understand the changes that you make, and conversely identify changes that other people in your team have made. But as you start to build a library of complex blueprints, version control is critical for your sanity.
Thankfully with Cloud Assembly, you have some great controls to hand that you can make use of. Let’s first take a look at some of the benefits of versioning, and then delve into creating your own versions.
1. Identifying Changes
One use of versioning is to be able to compare different versions of your code. When did the breaking change occur, and what was the change that was made? As you can see above, Cloud Assembly has two different views when it comes to diffs - comparing the code, and comparing the canvas. In the provided example the canvas doesn’t show a lot of information, but when it comes to a blueprint with multiple objects, being able to hone in on the changes visually helps a lot.
2. Moving Between Versions
Hand in hand with identifying where changes occurred is the ability to roll back (or forward) between versions. Find a mistake in 0.6? Restore 0.5 as your working copy and carry on with your development.
3. Publish Known Good Blueprints
While it is expected that power users would have access to Cloud Assembly, it is also expected that they would share content that they create into a service catalog - in this case Service Broker. Within the version history view, you have the ability to release and unrelease blueprint versions, which results in them being made available in the Service Broker catalog.
Creating a new version of a blueprint is straightforward. Click on the version button, enter a version number, description and change log and you’re away.
Now that you have a handle on blueprint versioning, we can start on some more advanced concepts. Next up we will look at the blueprint schema, and extending basic infrastructure provisioning with cloud-init.
This post is part of a series. |
---|
Part 1 - Introducing VMware Cloud Automation Services |
Part 2 - Basic Blueprinting in Cloud Assembly |
Part 3 - This Article |
Part 4 - Getting Started with the Cloud Automation Services API |
Part 5 - Working with Blueprint Inputs |