Introduction
vRealize Orchestrator has been around for over 10 years and is the de facto automation / integration / orchestration tool from VMware. The product is free to use as long as you have a paid eligible license for vCenter or vRealize Automation. vRO also features an easy to use graphical user interface where one can easily visualize elements and flow and a rich plugin ecosystem, allowing easy integration with a large number of other products and systems from vendors like Microsoft, HPE, F5 etc.
Starting with The Basics
As you probably already know, the user interface is easy to use and provides drag-and-drop functionality for elements on a workflow as well as a scripting IDE with auto-complete and some level of code-linting and design-time checks.
In my experience, vRO has allowed scripters and infrastructure admins to easily write scriptable tasks and create workflows to automate and integrate a multitude of systems. As reliance on vRO tends to grow, workflows begin to grow more complex, and the number of vRO developers grows, we start to find that managing code and releases becomes exponentially more challenging.
The next level - vRO Dojo
In discussions around proliferating awareness on this subject, I introduced the analogy of yellow belt versus black belt in vRO, where we begin to develop a great deal of finesse in delivering vRO code. In so doing, Chris Hampton, a brilliant colleague of mine, coined the term “vRO Dojo”.
As we begin on a journey to mastering a mature process around code management, we start to become masters of vRO software development and integrating our process into a managed lifecycle, enforcing standards and quality, adopting a CI/CD approach to our code.
Yellow Belt
When we start out with vRO, the user interface is easy. We can drag elements onto a workflow, create scriptable tasks, introduce conditions, timers, loops, nested workflows and so forth. For a single developer in a small environment, this works perfectly.
As we begin to work more with vRO, we start to understand that there are smarter, more efficient ways of designing our workflows. Perhaps we start modularizing reusable code into Actions, use Configuration Elements on Workflow variables to ease operational changes. Maybe we start understanding that using multiple actions in a workflow provides a performance advantage over using multiple workflows to achieve the same result.
This is part of the journey, and perhaps we can begin to identify ourselves with a blue belt, however, as we progress and create more complex workflows, managing these changes between DEV, QA and PROD quickly uncovers some challenges.
What happens when other developers are working on the same workflow as me, simultaneously?
How can I tell exactly what changes are going into a release and how do I track and manage that release?
How do I implement automated code quality checks like unit testing and quality gates during builds?
How do I see who changed what throughout a development cycle?
What happens if someone changed code that I’m unaware of and I’m pushing this into PROD?
What process can I use to enforce code reviews to ensure we’re all adopting best practices?
As we progress on our journey to creating a mature development lifecycle, we begin to realize that we need another way of doing things…
Black Belt
If you refer to my previous article, it shows the basic approach to implementing a more mature set of tools to compliment vRO development and becoming a vRO Black Belt.
By using VS Code and using Typescript, we can start implementing strong typing which makes our code a lot more robust at design time. In addition, the ability to check in actual code (Javascript and / or Typescript flies), as opposed to code embedded in a bunch of XML files, allows us to plug in code analysis tools at a source control level. This means we can leverage automated code analysis which reports on any less-than-desirable practices like declaring variables out of scope, declaring unused variables, incorrect scoping, etc.
Furthermore, we have the ability to debug code against vRO from within VS Code, push packages straight from VS Code, check in to a git repository, create unit tests, define dependencies on other libraries and so forth.
Where it gets really interesting is where we have multiple developers. Each developer can create their own branches (allowing for simultaneous development) and each commit can be tracked. When a developer feels their code is ready for prime time, they can submit a merge request.
At this stage, we can enforce code reviews to ensure that our fellow developers’ changes are adhering to our standards. At this level, consider yourself a vRO black belt - you now have the ability to answer all of the questions you asked as a yellow belt:
What happens when other developers are working on the same workflow as me, simultaneously?
Create a branch in git
Commit your code
Submit a merge request through your code repo (Github / Gitlab / Bitbucket etc). Any conflicts are immediately visible when merging and can be fixed on the spot.
How can I tell exactly what changes are going into a release and how do I track and manage that release?
Set up automated builds and pipelines through your source repository
View reports on builds and view all of the approved merges which can show what was changed and by whom
How do I implement automated code quality checks like unit testing and quality gates during builds?
Integrate systems like Bamboo and Jasmine with Bitbucket
Code quality checks will reveal bad practice and provide reports
Failed unit tests will fail a build and provide visibility on erroneous code
How do I see who changed what throughout a development cycle?
Source control like Gitlab, Github and Bitbucket shows all commits for a merge request and shows a historic progression of changes, easily viewable.
What happens if someone changed code that I’m unaware of and I’m pushing this into PROD?
If you use source control correctly, this shouldn’t ever happen.
What process can I use to enforce code reviews to ensure we’re all adopting best practices?
Code reviews can be enforced upon merge requests, allowing for more control and visibility on all aspects of code changes