I recently wrote up a playbook for disciplined spiking — “The Art of Spiking” — as a GitHub Discussion, with a GitOps promotion workflow (ArgoCD + Kargo) as the running example. Capturing it here as a post as well, so the reasoning survives independently of that thread. A spike is not “write throwaway code and see what happens.” It is still an Enabler Story, with its own best practices. Nine of them, in my experience, matter the most.

🧗 Git as your climbing rope

Even a local, solo exploration deserves a local repo. Spiking means trying things that might not work, so you want to revert fast and cheap. Light, easy, already in your muscle memory — there is no excuse not to use it from the first minute.

📓 Track history as you go, not at the end

Write down steps, decisions, dead ends — in markdown, with snippets and screenshots — while they are still fresh, not reconstructed from memory once the spike is “done.” On my GitOps spike this became a running README.md (links to the articles and docs that shaped my thinking) and a CONTRIBUTING.md full of the exact commands and dashboard screenshots needed to reproduce the setup. That log is what let me pick the spike back up days later without re-deriving anything.

🌿 One branch per unknown

Keep main clean and let each exploration path live on its own branch. On the GitOps spike that meant a shared prereq branch, then three parallel branches — argocd, kargo, private_reg — each isolating one concern, merging back only once proven out. It turns a tangle of “what did I change for what reason” into a readable graph.

🔍 PRs are not just for review — they’re a diff you can read

Opening a PR against your own spike branch gives you the same diff view used in every migration tutorial you have ever followed. I planned to use that view specifically to show the impact of scaling scenarios — a new application, a new deployment stage — before deciding whether the approach would hold up.

🎛️ Fewer variables, better signal

Spikes are already full of unknowns; don’t multiply them. Isolate one variable, or a small group, before combining. For the GitOps spike I deliberately swapped out everything that wasn’t the point: a local docker-desktop cluster instead of our real Kubernetes setup, a minimal alpine app instead of actual microservices, a throwaway registry and repo. Scope went down, but the inherent complexity — auth against a private repo and registry — stayed, which is exactly the part worth testing.

🗺️ List your exploration paths before you lose the thread

A simple markdown list or a mind map keeps the possibilities visible instead of scattered across your head and three browser tabs. It also becomes a reference the next spike can build on instead of re-discovering. Mine mapped Doc, Tech (Kargo, ArgoCD, Argo Rollouts), Authentication (repository, registry), and Scaling (new stage, new app, image/chart bumps) as four branches off one root.

🧩 Name your three actors

Every spike is really three things: the unknown you’re investigating, the world you already live in with its own constraints, and the bridge connecting them. Start with the unknown — understand the theory, then get hands-on with it — before worrying about how it fits your context. The trap is starting from the bridge: introduce an abstraction layer for a pattern you don’t understand yet, migrate your codebase toward it, and end up having invested in a header-interface anti-pattern for nothing. Get comfortable with the new paradigm on its own terms first. For GitOps, that meant setting aside the full existing Kubernetes complexity entirely while getting hands-on with ArgoCD and Kargo in isolation — only then asking what adopting them would actually require of our real environment.

🏛️ Artifacts are not optional polish

C4 diagrams for the architecture and components in play. A technology radar entry to make the assess/trial/adopt call explicit instead of implicit. Mind maps to sketch what downstream work might look like. Depending on the spike, you reach for one, two, or all three — but you reach for something.

📡 Check the radar before you re-invent the spike

Past knowledge — documentation, prior write-ups, community forums — saves time others already spent. On this one, our team’s radar showed ArgoCD had already been investigated over a year earlier. I read that report carefully, decided the GitOps ecosystem had moved enough in a year to justify a fresh look, and re-spiked it deliberately, pairing it with Kargo this time to get to state-of-the-art promotion pipelines. Re-spiking is sometimes the right call — but it should be a decision, not an accident of not having looked first.

Closing

None of these nine pillars demand heavyweight process. They are closer to hygiene: version control, a log, branches, diffs, scoped variables, a map of what’s left to explore, clarity on what’s new versus what’s already known, artifacts that outlive the spike, and a glance at what the team already knows before starting. Small habits, consistently applied, are what make a spike something the team can actually learn from — rather than two weeks that evaporate the moment the branch gets deleted.