DEV Community

Aisalkyn Aidarova
Aisalkyn Aidarova

Posted on

Developer CI Dev Stage Production

#cicd #devops #kubernetes #tutorial

explained:

  • Why each exists
  • What happens in each
  • Who is responsible
  • How Argo CD handles it

🔷 STEP 0 — First Understand the Problem

If we deploy directly to production:

Developer pushes → users see bugs
Enter fullscreen mode Exit fullscreen mode

That is dangerous.

So DevOps creates safe layers.

Think of it like a hospital:

You don’t send a medicine directly to patients.

You test it first.

🔷 ENVIRONMENT 1 — DEV

What is DEV?

Dev = playground.

Purpose:

  • Test if image builds
  • Test if container runs
  • Test if Helm works
  • Test if service reachable

This environment is allowed to break.

How GitOps Works in DEV

You create:

manual-app-helm/
    values-dev.yaml
Enter fullscreen mode Exit fullscreen mode

Argo CD Application:

manual-app-dev
Enter fullscreen mode Exit fullscreen mode

Watching:

  • branch: main
  • values-dev.yaml

When Jenkins updates image tag →
Argo CD auto deploys to DEV.

Who Uses DEV?

  • Developers
  • DevOps

They check:

  • Does app start?
  • Is port correct?
  • Any crash?
  • Logs OK?

🔷 ENVIRONMENT 2 — STAGE

What is STAGE?

Stage = rehearsal before production.

It should look like production.

Same:

  • Node size
  • Resources
  • Ingress
  • TLS
  • Scaling

How It Works

You create:

values-stage.yaml
Enter fullscreen mode Exit fullscreen mode

Argo CD Application:

manual-app-stage
Enter fullscreen mode Exit fullscreen mode

Watching:

  • branch: release OR
  • same branch but different values file

What Happens Here?

  • QA team tests
  • Integration tests
  • API tests
  • Performance tests
  • Security scans

If everything passes → ready for production.

🔷 ENVIRONMENT 3 — PRODUCTION

What is Production?

Real users.
Real traffic.
Real money.

This environment must:

  • Be stable
  • Be secure
  • Be approved

How GitOps Works in Production

Production deployment should NOT be automatic from main branch.

Common strategies:

Strategy 1 — Release Branch 

main → dev
release → stage
tag v1.0 → production
Enter fullscreen mode Exit fullscreen mode

Only approved code gets merged to release.

Strategy 2 — Manual Promotion

You manually change image tag in:

values-prod.yaml
Enter fullscreen mode Exit fullscreen mode

And push commit.

Argo CD deploys.

This creates audit trail.

🔥 Why This Is Important

Because CI only proves:

✔ Code compiles
✔ Docker builds

But it does NOT prove:

✔ Application logic works
✔ Database integration works
✔ External APIs work
✔ Performance is acceptable

That is why environments exist.

🔷 Real GitOps Multi-Env Structure

Your Helm repo could look like this:

manual-app-helm/
   charts/
   values-dev.yaml
   values-stage.yaml
   values-prod.yaml
Enter fullscreen mode Exit fullscreen mode

Argo CD apps:

manual-app-dev
manual-app-stage
manual-app-prod
Enter fullscreen mode Exit fullscreen mode

Each points to:

Same repo
Different values file
Different namespace

Example:

namespace: dev
namespace: stage
namespace: prod
Enter fullscreen mode Exit fullscreen mode

🔷 Deployment Flow Explained for Beginners

Let’s imagine version 15.

Step 1 — Developer pushes code

CI runs:

docker build
docker push
Enter fullscreen mode Exit fullscreen mode

Tag = 15

Step 2 — Jenkins updates values-dev.yaml

Now dev environment runs image 15.

Developers test.

Step 3 — Promote to Stage

DevOps changes:

values-stage.yaml → tag 15
Enter fullscreen mode Exit fullscreen mode

Argo CD deploys to stage.

QA tests.

Step 4 — Promote to Production

After approval:

values-prod.yaml → tag 15
Enter fullscreen mode Exit fullscreen mode

Argo CD deploys.

Users see new version.

🔥 Key DevOps Principle

We do not rebuild image for each environment.

We promote the SAME image.

This guarantees:

What was tested = what goes to production
Enter fullscreen mode Exit fullscreen mode

Very important concept.

🔷 Interview-Level Explanation

If asked:

Why separate environments?

Answer:

Because CI validates build integrity, but environments validate runtime behavior progressively to reduce production risk.

Simple Analogy

Dev = kitchen test
Stage = restaurant rehearsal
Prod = customers eating

You never experiment directly with customers.

Top comments (0)