Why GitOps on a POC Cluster#

Setting up ArgoCD on minikube is not about automating deployments for a local cluster – you could just run kubectl apply. The point is to prove the deployment workflow before production. If your Git repo structure, Helm values, and sync policies work on minikube, they will work on EKS or GKE. If you skip this and bolt on GitOps later, you will spend days restructuring your repo and debugging sync failures under production pressure.

Jenkins Multibranch Silent Skip After Branch Recreate#

Push a branch named fix/foo. Trigger a multibranch scan. The scan log shows Checking branch fix/foo and immediately moves to the next branch with no verdict line. No job appears under the multibranch. No build fires. Other branches scan and build normally.

This is Jenkins’s branch source plugin silently skipping a branch because its internal cache treats the name as a duplicate of a previously-deleted entry. The cache survives plugin restarts, multibranch rescans, and kubectl rollout restart jenkins. The reliable recovery is to push the same commits under a different branch name — the cache has no entry for the new name and processes it cleanly.

An agent writes a 200-line streaming-client implementation against your project’s pinned SDK. It compiles cleanly in the model’s head. The test code references SomeStreamEvent, the streaming function signature is func NewStreaming(ctx, params) (stream, error), and the iteration loop uses stream.Recv(). The reviewer skims it, sees plausible naming, approves. CI fails with “undefined: SomeStreamEvent”. The agent escalates: “the SDK is broken — package not found.” Hours later, somebody figures out that the SDK they’re pinned to has none of those symbols. The import path is different. The function returns one value not two. The iteration pattern is Next() / Current() / Err(), not Recv(). The model invented the API.

A single-node minikube cluster on Docker Desktop runs the entire control plane, kubelet, every PVC, every Secret, and the container image cache inside one VM whose disk is one file: ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw on macOS. When that file is lost or corrupted, every piece of cluster state goes with it in a single event. There is no “node failure vs storage failure” distinction to design around. Every backup strategy that assumes those are separable does not apply.

Advanced Git Operations#

These are the commands that separate someone who uses Git from someone who understands it. Each one solves a specific problem that basic Git workflows cannot handle.

Interactive Rebase#

Interactive rebase rewrites commit history. Use it to clean up a branch before merging.

# Rebase the last 4 commits interactively
git rebase -i HEAD~4

This opens an editor with your commits listed oldest-first:

pick a1b2c3d feat: add user export endpoint
pick e4f5g6h WIP: export formatting
pick i7j8k9l fix typo in export
pick m0n1o2p feat: add CSV download button

Change the commands to reshape history:

Interactive Rebase#

Interactive rebase rewrites commit history before merging a feature branch. It turns a messy series of “WIP”, “fix typo”, and “actually fix it” commits into a clean, reviewable sequence.

Start an interactive rebase covering the last 5 commits:

git rebase -i HEAD~5

Or rebase everything since the branch diverged from main:

git rebase -i main

Git opens your editor with a list of commits. Each line starts with an action keyword:

Agent Context Preservation for Long-Running Workflows#

The context window is the single most important constraint in agent-driven work. A single-turn task uses a fraction of it. A multi-hour project fills it, overflows it, and degrades the agent’s reasoning quality long before the task is complete. Agents that work effectively on ambitious projects are not smarter – they manage context better.

This article covers practical, battle-tested patterns for preserving context across long sessions, delegating to sub-agents without losing coherence, and avoiding context pollution – the gradual degradation that happens when irrelevant information accumulates in the working context.

Why Change Management Matters#

Most production incidents trace back to a change. Code deployments, configuration updates, infrastructure modifications, database migrations – each introduces risk. Change management reduces that risk through structure, visibility, and accountability. The goal is not to prevent change but to make change safe, visible, and reversible.

Change Request Process#

Every infrastructure change flows through a structured request. The formality scales with risk, but the basic elements remain constant.

Designing Agent-Ready Projects#

An “agent-ready” project is just a well-documented project. Every practice that helps an agent — clear conventions, explicit commands, tracked progress, documented decisions — also helps a new team member, a future-you who forgot the details, or a contractor picking up the project for the first time.

The difference is that humans can ask follow-up questions and gradually build context through conversation. Agents cannot. They need it written down, in the right place, at the right level of detail. Projects that meet this bar are better for everyone.

Git Branching Strategies#

Choosing a branching strategy is choosing your team’s speed limit. The wrong model introduces merge conflicts, stale branches, and release bottlenecks. The right model depends on how you deploy, how big your team is, and how much you trust your test suite.

Trunk-Based Development#

Everyone commits to main (or very short-lived branches that merge within hours). No long-running feature branches. No develop branch. No release branches unless you need to patch old versions.