---
title: "GitOps | Skills We Assign For | Azendo"
description: "GitOps as an operating model — Git as source of truth, review and audit, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/gitops/"
---

[Skills](https://azendo.co/skills/) CI and delivery 

# GitOps.

GitOps is an operating model where the desired state of a system is declared in Git and an automated controller reconciles reality toward it. Deployment becomes a merge, and the repository is the audit log.

## Where GitOps fits on a long engagement.

The operational gains follow from one property: every change to production is a commit. Rollback is a revert, audit is the log, and review is the existing pull request process rather than a separate change-approval system. For regulated environments that alignment is worth more than the deployment automation itself.

It fails in predictable ways. Secrets cannot sit in Git, so a sealed-secret or external-store mechanism is required before anything else works. And the model depends on nobody changing things by hand — one break-glass path used routinely, and the repository becomes a description of what someone once intended rather than what is running.

## What an assigned team does with GitOps.

The hard part is cultural rather than technical. Engineers used to fixing production directly experience the model as friction, and the honest answer is that it is friction, exchanged for the ability to know what is running.

Getting that adopted rather than worked around takes standing involvement rather than a handover, which is what a [dedicated software development team](https://azendo.co/services/dedicated-development-team/) provides.

## What we use GitOps for.

* Deployment as a reviewed merge The existing pull request process becoming the change-approval process.
* Audit that needs no assembly A complete history of production changes, already in the repository.
* Secrets handled before adoption A sealed-secret or external-store path in place, because the model does not work without it.

## How GitOps capacity is assigned.

GitOps adoption is assigned under [devops managed services](https://azendo.co/services/cloud-and-devops/), with secret management resolved before the model is rolled out rather than after.

## Roles we assign GitOps for

* [Platform Engineer Cloud and DevOps](https://azendo.co/services/cloud-and-devops/platform-engineer/)

## Service lines it sits in

* [Cloud and DevOps](https://azendo.co/services/cloud-and-devops/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in ci and delivery

* [Jenkins — skill we assign for](https://azendo.co/skills/jenkins/)
* [GitLab CI — skill we assign for](https://azendo.co/skills/gitlab-ci/)
* [Fastlane — skill we assign for](https://azendo.co/skills/fastlane/)
* [Codemagic — skill we assign for](https://azendo.co/skills/codemagic/)
* [TestFlight — skill we assign for](https://azendo.co/skills/testflight/)
* [App Store Connect — skill we assign for](https://azendo.co/skills/app-store-connect/)
* [Play Console — skill we assign for](https://azendo.co/skills/play-console/)
* [CodePush — skill we assign for](https://azendo.co/skills/codepush/)

## Tell us what your roadmap needs GitOps for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)