Microsoft Azure doesn't want you to do GitOps

There are many definitions of GitOps, but in my opinion, they boil down to a simple but powerful idea of storing your Ops-related things, such as pipelines, playbooks, Helm charts, configs, env var libraries etc., in Git, so a Git repository can be used as a single source of truth.

Operational artifacts stored in Git are:

• Written as plain text (or as ciphered text in some cases)
• Easily searchable
• Version-controlled

Another less obvious result of the previous three:

• (Much more) portable across environments

The last point here is important because it's clearly in conflict with cloud players' desire to have you locked in. We tried to implement GitOps at my $dayjob and figured it out the hard way. We're an MS Azure shop so I'll mostly be talking about Azure, but all the points are relevant for other major cloud vendors.

A lot of functionality in Azure operates through GUI, and Microsoft seems to be OK with it. Azure Classic Pipelines, a GUI pipeline builder, was kinda, but not really, deprecated. It still doesn't have its EOL date specified, and it's unlikely to go anywhere anytime soon. Release Pipelines, which are also managed from GUI, is here to stay. Same as Library, Azure-specific key-value storage for variable groups. Even YAML-based pipelines have UI helpers. So while they technically can be edited offline, the only effective way to do it is from a web UI.

The reason for such persistence of GUIs is, in my opinion, twofold. First, Microsoft always was UI-centric. It started to change some time ago, but old habits die slowly. Microsoft was never CLI-first, terminal first, and it shows. Secondly, Microsoft (and other cloud providers) pretty much _do_ want you to use their proprietary GUIs because it locks you in and make your infrastructure less portable. Yes, technically, nobody is stopping you from storing everything as text files, but this is not the _default way to do things here_. If you decide to go this way, you're on your own. All official documentation assumes there is a right way to do things, and it includes using default GUIs. If you go to help forums, other users will suggest you GUI-based solutions, and official representatives will do the same, because they read and follow the same docs.

Even if you're OK with vendor lock-in and store your YAML pipelines in Git, implementing GitOps in Azure remains challenging. Aforementioned Library, for instance, is pretty Git-hostile. Release pipelines can be exported as JSON, but the output is clearly not intended to be human readable even after beautification. Deployment groups clearly don't want to be Gitified. Variable groups from Library can be cloned, but not exported (and good luck moving them even to another project within the same Azure organisation). Agent pools (Azure inventory) - only GUI. Service connections (aka 3rdp connections) - only GUI. All these things could be easily stored as text files, but Azure doesn't want you to do it.

Now, I don't hate UIs and I'm not saying these design choices are necessarily bad. They definitely could be convenient in certain scenarios. I'm just saying that these choices play really bad with GitOps practices. What's even worse, most of GUI implementations are lackluster and even some basic functionality is not there. For example, variable groups are always sorted alphabetically, and this sorting is enforced on save. So if you add a record and save, it will jump to its place according to the alphabetical order, even if it means that it disappears from the viewport. It's not rare to have tens or even hundreds of variables in a group, and the lack of ergonomics when working with such large lists is apparent. Absence of bulk operations is another offender.

You probably will be more lucky if you have Kubernetes or Terraform because they are innately text-based. But if you want a simpler setup or, as in our case, work with VDS, implementing GitOps on Azure is going to be challenging.