How GitOps Revolutionizes Cloud‑Native Deployments: Lessons from Horizon CD

Why Traditional Host Deployments Fail

Manual host deployments rely on ticket‑based requests and tools like Ansible, requiring SSH setup, handling heterogeneous environments, and prone to script ordering errors, resulting in low efficiency, high error rates, and poor quality assurance.

Inconsistent environments : Scripts must anticipate many host states (SSH, dependencies, prior installations).

No transactional guarantees : Failures leave services in partial states.

Collaboration difficulty : Multiple developers editing the same script leads to conflicts.

Rollback challenges : Manual reversal steps are required.

Permission and audit issues : Root access is needed, making control and auditing hard.

Characteristics of Cloud‑Native Deployments

Cloud‑native stacks—containers, service mesh, microservices, immutable infrastructure, and declarative APIs—drive frequent, multi‑replica, multi‑environment releases, demanding higher automation, version control, consistency, transactional safety, and collaborative workflows.

What Is GitOps?

GitOps treats a Git repository as the single source of truth, storing declarative configuration that automation tools apply to target environments. Git provides versioning, rollback, and multi‑person collaboration; declarative configs ensure readability, idempotence, and transactional application; automation eliminates human error and speeds up deployments.

Git Repository

Developers use familiar Git workflows (branches, pull requests, code review) to manage configuration files, enabling version control, rollback, and peer review of changes.

Declarative Configuration

Configurations describe the desired system state without specifying execution steps, making them easy to write, review, and manage. They are inherently idempotent and transactional—either the whole configuration applies successfully or nothing changes. Kubernetes manifests are a typical example.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      - name: example-container
        image: example-image
        resources:
          limits:
            cpu: "1"
            memory: 512Mi
          requests:
            cpu: 500m
            memory: 256Mi

Automation Tools

Tools such as GitLab CI, GitHub Actions, or dedicated GitOps engines like Argo CD watch the Git repo and automatically synchronize changes to the cluster, handling deployment, rollback, monitoring, and alerts.

With Argo CD, creating a Git repository and an Argo CD Application is enough for continuous synchronization; any change in the repo triggers an automatic sync.

GitOps in Practice at NetEase Cloud Music

The team adopted a GitOps pipeline built on GitLab CI and Argo CD to manage dozens of control‑plane components (Grafana, Prometheus, Argo Rollout, etc.) across multiple Kubernetes clusters.

Repository Layout

Each service has three repositories: source code, Helm chart, and a configuration repo holding values.yaml. The configuration repo is the single source for environment‑specific settings, referenced by Helm dependencies.

Change Workflow

Developers modify values.yaml, open a merge request, trigger CI validation, obtain peer review via a bot, and merge to master. The pipeline runs helm upgrade to apply changes. Rollback is achieved by re‑running the previous pipeline run or reverting the commit.

Horizon CD Platform

To reduce the overhead of managing many repositories, the team built Horizon, a GitOps‑based CD platform on top of Argo CD. Users fill a web form with application name, image, replica count, and environment details. Horizon then generates the necessary GitOps repository, creates the appropriate Argo CD Application, and triggers synchronization.

Horizon tracks the state of each application; if the live cluster diverges from the Git repo, Argo CD marks the application OutOfSync, alerting operators.

Configuration Files Overview

Chart.yaml

: Standard Helm chart metadata with dependencies on Horizon templates. application.yaml: Captures user‑provided form data. pipeline.yaml: Defines CI build type (default dockerfile) and Dockerfile path. sre.yaml: Stores admin‑level settings such as ingress, node affinity, and over‑subscription ratios. env.yaml: Holds environment name, region, namespace, registry, and ingress domain. restart.yaml: Used to trigger a rolling restart by updating a timestamp.

Limitations and Open Issues

Configuration duplication across many repos makes bulk updates cumbersome.

Secrets stored in plain text in Git require additional encryption tooling; existing solutions like git‑secret are not yet seamless.

No unified standard for rollback strategy (reset vs. re‑run CI) or for mapping environments to repositories (one repo per env vs. one repo with multiple branches).

Conclusion

GitOps, combined with a platform like Horizon, enables highly automated, version‑controlled, and auditable deployments across dozens of environments, boosting release velocity by more than tenfold while maintaining quality. Although challenges such as secret management and repository scaling remain, the approach aligns closely with DevOps principles and continues to evolve within the cloud‑native ecosystem.