← Back to the blog

Git

VCF Automation – Native Git Integration vs Alternatives

Git integration with VCF Automation comes up regularly in conversations about GitHub and GitLab. Native integrations suit their intended uses, but misunderstandings about their scope can lead to disappointment.

Before choosing an integration, establish which content it can manage from Git. This post explains the native options, their limitations and the alternatives you may need.

VCF Automation relies on the bundled VCF Operations Orchestrator product for its full automation capabilities. Orchestrator is often overlooked because it is a separate product. The two products integrate with Git differently, so consider both.

I divide the uses of Git into three categories:

  • Infrastructure – Configuration stored in Git that defines the platform's compute, storage and networking, whether physical or software-based. This is often called infrastructure as code, although the term is used more broadly.
  • Content – Configuration, blueprints, workflows and other code developed for end users through a traditional development lifecycle. Content typically consumes the underlying infrastructure.
  • Consumers – Users, processes and tools that access platform content through the API or GUI. They can choose how to consume it, so their approaches are outside this post's scope.

Each category is likely to need different tools, methods and a different lifecycle.

This post focuses on Git support rather than examining orchestration tools in detail.

Native Git support in VCF Automation

The following tables list infrastructure configuration and content that could be stored in Git. They show which items the native integrations supported when I wrote this post.

VCF Automation and VCF Operations Orchestrator have separate tables.

Infrastructure configuration

These are the most common infrastructure configuration items:

VCF Automation:

Item Native Git Integration Support
Cloud Accounts Not Supported
Cloud Zones Not Supported
Network Profiles Not Supported
Storage Profiles Not Supported
Image Mappings Not Supported
Flavor Mappings Not Supported
Projects Not Supported

VCF Operations Orchestrator:

Item Native Git Integration Support
Inventory / Plugin endpoints Not Supported
Policies Not Supported
Environments Not Supported

Content

The following content is consumed by end users or supports that consumption:

VCF Automation:

Item Native Git Integration Support
Templates (blueprints) Pull only. Pushing template changes requires extra work or workarounds. Import fails if the version number is not incremented for every commit, or if the template contains syntax errors.
Property Groups Not Supported
Custom Resources Not Supported
Resource Actions Not Supported
Subscriptions Not Supported
ABX Actions One way only. Content can only be pulled from a Git Repository and changes to an ABX Action cannot be pushed.
Content Sources Not Supported
Catalog Items Not Supported
Custom Forms Not Supported
Policy Definitions (Content Sharing, Approval, Deployment Limit, Resource Quota, Day 2 Actions, Lease) Not Supported

VCF Operations Orchestrator:

Item Native Git Integration Support
Workflows Supported*
Actions Supported*
Configurations Supported*
Resources Supported*

* Orchestrator can present and activate only one branch at a time. A typical branching strategy does not handle environment-specific content, such as configurations, by itself. You need additional work to select the correct content for each environment.

Alternatives to native Git integration

Use the APIs

All VCF Automation services expose APIs for managing infrastructure and content programmatically. You can build a custom solution that reads configuration from Git. For example, a PowerShell or Python script could process JSON documents describing the infrastructure.

This provides the most flexibility, but requires more development and maintenance.

The VMware Aria Automation API Documentation page provides details of each of the available APIs.

Use orchestration tools such as Terraform

Terraform is often suggested among the available orchestration tools. It was designed to consume content from cloud providers such as AWS. Its providers also support infrastructure as code for VCF Automation infrastructure. I consider it a good fit for infrastructure configuration, with code and state held in a Git repository.

I find Terraform less suited to content management. It can handle parts of the process, but was not designed for that purpose. I may cover its use for infrastructure configuration in a future post.

Use Build Tools for VMware Aria

Build Tools for VMware Aria is a framework for developing VCF Automation and Orchestrator content. I cover it in my Build Tools for VMware Aria series. I consider it the best option for managing content through a traditional development lifecycle. Its content is designed to live in Git, with Maven providing supporting project management capabilities.

Build Tools has limited support for infrastructure configuration, covering items such as Flavor Mappings and Image Mappings. This makes it less suitable for managing the infrastructure itself.

Conclusion

Native Git integrations do not manage the infrastructure as code. Their support for Templates and ABX Actions is also limited. In my experience, two constraints make them frustrating to use:

  • Every template change needs a version increment, however small the change. I used a Git hook to automate this after repeatedly forgetting it.
  • The integration pulls in one direction. You must export content and save it in Git manually.

Keep the Infrastructure, Content and Consumer categories distinct. Calling all three infrastructure as code makes requirements harder to discuss. Choose a solution for each need rather than expecting one tool to cover everything.

Let consumers choose how they use the content. I have seen engineers try to design one solution for everyone, with every configuration stored in Git. Different people and teams have different needs and ways of consuming infrastructure.

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

Join the discussion

Sign in with GitHub to leave a comment. View discussions on GitHub.

← Explore more articlesFollow via RSS ↗