Creates GitOps tutorial Lesson 2: Promoting from Stage to Production by alexcreasy · Pull Request #20 · streamshub/streamshub-gitops

alexcreasy · 2026-07-29T16:52:50Z

NOTE: This PR is SECOND in a stack of 3 PRs and must be merged in order:

This adds the interactive content for the second lesson for the GitOps tutorial series.

To run:
Checkout the README.md in the lessons/ directory which will point you to instructions to setup the infrastructure and then to the first lesson.

Note: the documentation is to give an idea of how the lesson will go. In a later PR the prose will be re-written to improve the flow, make them more engaging and better elaborate on the lessons as required.

…tion Signed-off-by: Alex Creasy <alex@creasy.dev>

Signed-off-by: Alex Creasy <alex@creasy.dev>

kornys · 2026-07-29T18:13:31Z

+info "Creating ArgoCD applications for staging and production..."
+
+kubectl apply -f - <<EOF
+apiVersion: argoproj.io/v1alpha1


Why both apps are defined inside shell script?

Good point, I'll move them out into separate yaml files.

thanks!

tomncooper

Looks good, I tested the README instructions on KIND (podman) running on my Fedora 44 box.

I had a few comments, as well as some carried over from my lesson 1 review.

tomncooper · 2026-07-30T13:14:17Z

+
+---
+
+## Prerequisites


As I said before, this should only show the delta compared to the requirements in the 00-setup list.

tomncooper · 2026-07-30T13:15:51Z

+
+## Background: Why environments matter
+
+In Lesson 1 you made a single change and watched it reach the cluster automatically. In practice, organisations don't push changes directly to production — they promote changes through a chain of environments: developers push to **staging** first, validate the change, then promote to **production**.


Suggested change

In Lesson 1 you made a single change and watched it reach the cluster automatically. In practice, organisations don't push changes directly to production — they promote changes through a chain of environments: developers push to **staging** first, validate the change, then promote to **production**.

In Lesson 1 you made a single change in the configuration hosted in the git repository and watched it be applied to the the cluster automatically. In practice, organisations don't push changes directly to production — they promote changes through a chain of environments: developers push to **staging** first, validate the change, then promote to **production**.

tomncooper · 2026-07-30T13:16:50Z

+
+In Lesson 1 you made a single change and watched it reach the cluster automatically. In practice, organisations don't push changes directly to production — they promote changes through a chain of environments: developers push to **staging** first, validate the change, then promote to **production**.
+
+The key insight: promotion in a GitOps world is not a deploy command. It is a Git change. You describe what each environment should look like in Git, and ArgoCD continuously reconciles each environment to match its description. Promoting a change means updating the description for the target environment and pushing.


Suggested change

The key insight: promotion in a GitOps world is not a deploy command. It is a Git change. You describe what each environment should look like in Git, and ArgoCD continuously reconciles each environment to match its description. Promoting a change means updating the description for the target environment and pushing.

The key insight: promotion from one environment to another, in a GitOps world, is not a deploy command. It is a change in a git repository. You describe what each environment should look like in the configuration in the repo and ArgoCD continuously reconciles each environment to match its description. Promoting a change means updating the description for the target environment and pushing.

tomncooper · 2026-07-30T13:18:29Z

+
+The key insight: promotion in a GitOps world is not a deploy command. It is a Git change. You describe what each environment should look like in Git, and ArgoCD continuously reconciles each environment to match its description. Promoting a change means updating the description for the target environment and pushing.
+
+**Kustomize overlays** are the standard mechanism for this. You keep a shared base configuration and then have one overlay per environment that references the base and adds or patches environment-specific resources. ArgoCD points a separate Application at each overlay.


Suggested change

**Kustomize overlays** are the standard mechanism for this. You keep a shared base configuration and then have one overlay per environment that references the base and adds or patches environment-specific resources. ArgoCD points a separate Application at each overlay.

**Kustomize overlays** are the kubernetes-native mechanism for managing configurations. You keep a shared base configuration and then have one overlay per environment that references the base and adds or patches environment-specific resources. ArgoCD points a separate Application at each overlay.

Have you described what an ArgoCD Application is? I wonder if we need more description of the generic CD process and then a brief description of how ArgoCD specific things like Applications map onto that?

tomncooper · 2026-07-30T14:21:15Z

+- Adds its own `namespace.yaml` (to create the `kafka-staging` namespace)
+- Adds `topic.yaml` (the Kafka topic)
+
+The ArgoCD `kafka-staging` Application points to this directory. When kustomize renders it, ArgoCD gets the full set of resources: namespace, Kafka cluster, KafkaNodePool, and topic — all in the `kafka-staging` namespace.


I wonder if it would be useful to tell the reader they can render the full overlay themselves if they want to see kustomize in action:

kubectl kustomize manifests/overlay/staging

tomncooper · 2026-07-30T14:32:14Z

+git push
+  └─▶ Gitea receives the commit
+
+ArgoCD polls Gitea every 3 minutes


Can we reduce this, I had to wait for (what seemed like) a very long time for something to happen once I pushed the change. For such a small demo, could it be 1 min or event 30 seconds?

My thoughts are we just give the user the command to force a reconciliation immediately - it's listed down the end as an "optional" step right now, but you won't see it unless you are actively looking for it.

I'll see if I can reduce the interval as well, but having text along the lines of "Normally your changes would be applied after $INTERVAL, but to save waiting, run this command to apply the change instantly" ?

tomncooper · 2026-07-30T14:37:10Z

+#!/usr/bin/env bash
+set -euo pipefail
+
+CLUSTER_NAME="gitops-tutorial"


As I said before lets put all these constants in a common script

tomncooper · 2026-07-30T14:37:46Z

+
+# ─── Step 1: Validate infrastructure ──────────────────────────────────────────
+
+info "Validating tutorial infrastructure..."


These could be function in a common module

tomncooper · 2026-07-30T14:38:57Z

+info "Cleaning up previous lesson state..."
+
+# Remove the lesson-1 ArgoCD Application (no cascade finalizer, so this is instant).
+kubectl delete application kafka-tutorial -n argocd --ignore-not-found 2>/dev/null || true


The application name and namespaces in these commands should be variables, again probably in a common script file

tomncooper · 2026-07-30T14:40:19Z

+done
+
+kubectl set env deployment/strimzi-cluster-operator -n strimzi-operator \
+  STRIMZI_NAMESPACE='kafka-staging,kafka-production'


Why not just have strimzi watch all namespaces cluster-wide?

Why have strimzi watch all namespaces cluster wide when these are the only namespaces the tutorial will use?

Not being facetious, genuinely curious what that achieves?

alexcreasy added 2 commits July 29, 2026 17:49

Adds interactive content for lesson 2: promoting from stage to produc…

d1e4298

…tion Signed-off-by: Alex Creasy <alex@creasy.dev>

Fix issue where teardown hangs

f298db4

Signed-off-by: Alex Creasy <alex@creasy.dev>

alexcreasy requested a review from tomncooper July 29, 2026 16:53

kornys requested changes Jul 29, 2026

View reviewed changes

This was referenced Jul 30, 2026

Adds the practical elements for lesson 1 of the GitOps tutorial series. #19

Open

Adds GitOps interactive lesson 3 - rollback a breaking change #21

Open

tomncooper reviewed Jul 30, 2026

View reviewed changes


		## Background: Why environments matter

		In Lesson 1 you made a single change and watched it reach the cluster automatically. In practice, organisations don't push changes directly to production — they promote changes through a chain of environments: developers push to staging first, validate the change, then promote to production.

	In Lesson 1 you made a single change and watched it reach the cluster automatically. In practice, organisations don't push changes directly to production — they promote changes through a chain of environments: developers push to staging first, validate the change, then promote to production.
	In Lesson 1 you made a single change in the configuration hosted in the git repository and watched it be applied to the the cluster automatically. In practice, organisations don't push changes directly to production — they promote changes through a chain of environments: developers push to staging first, validate the change, then promote to production.


		In Lesson 1 you made a single change and watched it reach the cluster automatically. In practice, organisations don't push changes directly to production — they promote changes through a chain of environments: developers push to staging first, validate the change, then promote to production.

		The key insight: promotion in a GitOps world is not a deploy command. It is a Git change. You describe what each environment should look like in Git, and ArgoCD continuously reconciles each environment to match its description. Promoting a change means updating the description for the target environment and pushing.

	The key insight: promotion in a GitOps world is not a deploy command. It is a Git change. You describe what each environment should look like in Git, and ArgoCD continuously reconciles each environment to match its description. Promoting a change means updating the description for the target environment and pushing.
	The key insight: promotion from one environment to another, in a GitOps world, is not a deploy command. It is a change in a git repository. You describe what each environment should look like in the configuration in the repo and ArgoCD continuously reconciles each environment to match its description. Promoting a change means updating the description for the target environment and pushing.


		The key insight: promotion in a GitOps world is not a deploy command. It is a Git change. You describe what each environment should look like in Git, and ArgoCD continuously reconciles each environment to match its description. Promoting a change means updating the description for the target environment and pushing.

		Kustomize overlays are the standard mechanism for this. You keep a shared base configuration and then have one overlay per environment that references the base and adds or patches environment-specific resources. ArgoCD points a separate Application at each overlay.

	Kustomize overlays are the standard mechanism for this. You keep a shared base configuration and then have one overlay per environment that references the base and adds or patches environment-specific resources. ArgoCD points a separate Application at each overlay.
	Kustomize overlays are the kubernetes-native mechanism for managing configurations. You keep a shared base configuration and then have one overlay per environment that references the base and adds or patches environment-specific resources. ArgoCD points a separate Application at each overlay.


		# ─── Step 1: Validate infrastructure ──────────────────────────────────────────

		info "Validating tutorial infrastructure..."


		---

		## Prerequisites

Uh oh!

Conversation

alexcreasy commented Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomncooper left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

alexcreasy commented Jul 29, 2026 •

edited

Loading