Mastering Cloud‑Native DevOps: From Core Concepts to GitOps Release Pipelines

What Is Cloud Native?

Cloud native refers to building and running applications that fully exploit modern cloud environments—public, private, or hybrid—by using containers, micro‑services, service meshes, immutable infrastructure, and declarative APIs. It addresses the slow upgrades, monolithic architectures, and poor fault isolation of traditional applications.

Key Cloud‑Native Characteristics (Pivotal Definition)

Integration of DevOps

Continuous Delivery

Micro‑services

Containerization

DevOps in the Cloud‑Native Era – New Challenges

Speed without breaking stability – rapid business‑critical releases and elastic resource provisioning.

Balancing stability and agility – maintaining reliable services while supporting fast feature rollout.

Resource efficiency – automatic scaling based on workload peaks.

Innovation through DevOps integration and micro‑service architecture.

Typical Application Release Process

Developers push code, triggering a build that pulls source, compiles the application, builds a container image, pushes the image to a registry, and deploys the image to the target environment. This workflow already leverages containers, Kubernetes, and dynamic pod allocation, but still faces security, approval, and observability challenges.

GitOps Secure Release Model

Four core requirements:

Version management – each release version is tied to a Git commit ID for traceability.

Baseline management – enables reproducible testing and rapid rollback.

Secure release – includes permission control and approval workflows.

Fast feedback – improves development productivity.

Key characteristics of the GitOps approach:

Git repository as the single source of truth for any CI/CD pipeline.

Declarative application orchestration and build‑deploy models.

Automated, environment‑agnostic promotion of applications.

Pull‑request/Merge‑request‑driven pipeline execution.

Rapid feedback mechanisms.

GitOps Architecture and Workflow

The architecture separates application source code (e.g., application-java-demo) from build scripts (Jenkinsfiles for preview, staging, production). Branches map to environments: master → production, latest → pre‑release, feature branches → test environments. Developers can create branches and merge requests, but only administrators can approve merges to staging or production and trigger the corresponding Jenkins pipelines.

Developer creates a new feature branch.

Developer opens a Merge Request to latest.

The MR automatically triggers the preview-pipeline Jenkins job, which pulls the preview pipeline source, runs compilation, tests, container image build & push, deploys to a preview cluster, and sends a DingTalk notification.

Administrator reviews the preview, approves or rejects the MR.

Upon approval, the staging-pipeline job runs similarly, deploying to the staging cluster.

After successful staging validation, the administrator merges latest into master, triggering the production-pipeline which deploys to the production cluster.

Tools Supporting GitOps

Common tools include draft for generating Helm charts, skaffold for simplifying build‑deploy cycles, kaniko for daemon‑less image builds, helm for package management, and CI/CD engines such as Jenkins, Tekton, Argo CD, or Jenkins X.

Reference URL: https://pivotal.io/cn/cloud-native