Aria Automation integration with a Git solution like Github or Gitlab is a conversation that has come up a lot over the years and again very recently. What is often suggested is to use the native integration options that are provided within the product, which are fine for their intended use case but many misconceptions lead to disappointment. Therefore, it’s important to understand what content can be managed from a Git repository using the native functionality. I will address these in this post and provide an understanding of what can be achieved and the available alternatives (and in many cases, necessities).

Aria Automation uses Aria Automation Orchestrator, that plays a crucial role in unlocking the full automation capabilities. Orchestrator is often overlooked as it is a separate product (appliance) that is bundled together. These two products, by contrast, integrate with Git in different ways and therefore have to be taken into consideration.

When investigating options for using Git there are many different use cases for managing content, I break these down into 3 high-level categories:

• Infrastructure – This is configuration stored in Git that defines what the infrastructure for the platform should look like. This includes the configuration for compute, storage and networking, where the hardware is either physical or software-based. We often refer to this as ‘Infrastructure as Code‘, though this term is usually applied everywhere.
• Content – This is typically content developed and presented to the end users for consumption. Content typically includes configuration, blueprints, workflows and other code, which is managed in a more traditional development lifecycle. Content typically consumes the underlying infrastructure.
• Consumers – These are end users, processes, tools etc that consume content on the platform either via the API or the GUI. As consumers are free to choose how they consume content, it is not something I will discuss in this post.

Each category could and will almost certainly use a different set of tooling, methodologies and lifecycle.

This post will not discuss orchestration tools in detail, as the aim is to look at this purely from a Git perspective.

Aria Automation Native Git Support

The following sections provide a list of infrastructure items and content that could potentially be managed in a Git repository and what the currently available ‘out of the box’ integration supports.

A separate section is provided for Aria Automation and Aria Automation Orchestrator.

Infrastructure Configuration

Below is a list of the most common infrastructure-related configurations in Aria Automation and Aria Automation Orchestrator.

Aria Automation:

Aria Automation Orchestrator:

Content

Below is a list of content that can be managed in Aria Automation and Aria Automation Orchestrator. Content is generally consumed by end users (or supports that goal).

Aria Automation:

Aria Automation Orchestrator:

* Only a single branch can be presented to Orchestrator and made active at any time. In a typical branching strategy, there is no way to handle environment-specific content (I.e. Configurations). Additional effort would be required to ensure the correct content is selected for the respective environment.

Aria Automation Alternative Git Support

Using the API’s

All of the Aria Automation services have an API that allows Infrastructure and content to be managed programmatically. This allows any ad-hoc solution to be used and the configuration can be stored and read from a Git Repository. An example might be a set of JSON documents that describe the infrastructure, which can be processed in a script written in PowerShell or Python.

This is the most flexible option available but requires much more involvement and maintenance to support.

The Aria Automation API Docs page is useful with details of each of the APIs available.

Using Orchestration Tools such as Terraform

There are many orchestration tools available, but Terraform is always the one which comes up in discussions. Whilst Terraform is a great tool, it was designed to consume content from big cloud providers like AWS. However, Terraform does include providers that can be used to facilitate an Infrastructure as Code approach to managing the Aria Automation Infrastructure. I believe Terraform would be a good use case for the Infrastructure Configuration where the code and state can be held in a Git Repository.

Terraform is going to struggle however when it comes to content. It can do parts of what is needed, but it isn’t designed for this purpose. I will likely cover the use of Terraform for infrastructure configuration in a future post.

Using the Build Tools for VMware Aria

The Build Tools for VMware Aria (which I have covered in this series) is a framework for developing content on the Aria Automation platform (inc Aria Automation Orchestrator). It is without a doubt the best option available when it comes to using the traditional development lifecycle approach to developing content. All content managed by the Build Tools is designed to be held in a Git repository and the Maven project management tool also has a lot of built-in capabilities to support this.

The Build Tools has very limited support for infrastructure configuration and only supports items such as Flavor Mappings and Image Mappings, which does not make it well suited for this purpose.

Conclusion

The native Git integrations are not designed to allow for the infrastructure itself to be managed as code. There is some support for content on the Aria Automation platform for Templates and ABX Actions, but even these are quite limited and frustrating to use. I have used them in the past and found myself constantly forgetting to increment the version on a template every time I made any change, be it minor or major (I ended up using a Git hook to automate this). The one-way ‘pull’ is also a problem as it still requires that content be exported and saved in the Git repository manually.

Consideration also has to be given to the 3 categories I listed above (Infrastructure, Content, Consumer) as I so often see these being bundled together as ‘Infrastructure as Code‘, which makes the conversations confusing and difficult. Focus on one, and find the right solution, don’t expect a one-size-fits-all all for everything.

When it comes to end users/consumers, my best advice would be to let them decide how they want to consume the content. I have been in many conversations with engineers who try and come up with a solution for everyone and have all the configurations stored in Git. This is novel but every person and team is different and they will each have their specific approach to consuming the infrastructure.

If you have any thoughts on this or good ways to approach these challenges, then please share.