A friend of mine runs a three-person commerce team, and for two years their deployment process was whoever was least busy that evening. It worked, mostly, until a Thursday night change took the checkout page down for six hours and nobody could say which of eleven edits had done it. That team did not need more people or a bigger budget. They needed their setup written down somewhere trustworthy and a piece of software willing to enforce it. That combination has a name — GitOps — and small teams adopt it successfully by walking a particular path, one step at a time, rather than flipping a switch. Here is that path, in the order that causes the fewest surprises.
Step 1: Write down what you already run
Before any tooling, spend a week being honest. List the services, the scheduled jobs, the DNS entries, the environment variables, the cron entries nobody remembers creating. Three lists are enough to start:
- What runs where: every service and job, with the machine or cluster it occupies.
- What connects to what: domains, certificates, queues, and third-party integrations by name rather than by secret value.
- What changed lately: the last ten modifications anyone remembers, and whether a record of them exists anywhere.
The output does not have to be elegant; it has to be true. This inventory becomes the seed of your repository, and just as valuably, it becomes the document you consult when deciding what to migrate first. Teams that skip this step discover their forgotten components later, usually at inconvenient moments. Those who do it properly find that planning digital growth before touching any tool is the same discipline that makes deliberate digital growth planning work anywhere else in the business.
Step 2: Give GitOps one repository with a sensible shape
Put the declarations in a single repository, laid out by purpose. Large organisations split theirs into clusters, infrastructure, tenants, and applications; a small team can survive with three folders. One rule matters more than the folder names: environments live in directories, never in branches. A staging folder and a production folder sit side by side, visibly different, easily compared. Branch-per-environment hides the differences inside merge conflicts and makes promotion a guessing game. While you are here, decide what will never enter this repository: customer records, payment details, media files. The repo describes the system; it must never become a database of the things the system holds.
Step 3: Install an agent and let it watch staging only
Choose a reconciler to do the watching; Argo CD and Flux dominate this category, and either will serve a team your size. Point it at the staging folder. Resist the urge to aim it at production on day one. The interesting part of setup is not installation; it is calibration. You will discover which fields your platform fills in by itself, which settings the agent keeps trying to undo, and which of your declarations were quietly wrong all along. Give the agent ownership of its own installation during bootstrap, so it can upgrade itself the way it upgrades everything else. A fortnight of watching it argue with reality in staging teaches more than any tutorial.
Step 4: Keep the sync manual at first
Almost every mature setup began with a period where the agent proposed changes and a human pressed the button. Run that way deliberately. Turn on drift alerts so you hear whenever the live system wanders from the record, and expect the first few alerts to be embarrassing — they will point at differences nobody knew existed. During these weeks you are really doing two things at once: learning how the tool behaves, and cleaning up the habits the tool will expose. Your first written decision document — which state store, which layout, which secrets approach, which drift policy — is worth drafting now, while the stakes are staging environments rather than revenue. Keep it short. A page that people actually read beats a policy nobody opens twice.
Step 5: Move GitOps into production one service at a time
When staging has been boring for a month, promote a single low-risk service. Keep automatic pruning switched off for the migration — the goal is to let the agent add and adjust without letting it delete anything you have not fully accounted for. Watch one full change cycle: proposal, review, merge, apply, confirmation. Then bring over the next service, and the next. Namespace by namespace is the pace that has worked for teams far larger than yours. Speed comes later, and it comes from confidence, not from rushing the early weeks. If your team wants a wider frame for where this fits, the DevOps career path and its progression gives useful context for how these responsibilities settle across roles.
Step 6: Add guardrails before you need them
Once production folders are live, the failure modes change character. Now a careless merge can remove something real, so deletion needs guarding: marking certain resource types prune-proof, and adding a check in your pipeline that flags any proposal which deletes something significant without an explicit sign-off. Credentials need tightening too — the agent should hold the least access that lets it work, not the keys to everything. And once a webhook is in place to speed up the agent’s polling, protect that endpoint with a shared secret, because it has no rate limiting of its own. None of this is glamorous. All of it is the difference between a system that bends and one that breaks.
Step 7: Rehearse the bad day
Sooner or later, an incident and the automation will want to occupy the same minute, and the automation usually wins unless you have planned for it. Practise the escape hatch: suspending the reconciler mid-incident, fixing the problem by hand, and then re-entering your changes through a proposal so the record catches up with reality. Do this in a calm quarter, not at 3 a.m. during an outage. A team that has rehearsed break-glass once responds with procedure instead of panic. For the broader picture of how delivery, cloud, and platform work knit together, how cloud, DevOps, and platform engineering reshape software delivery is a worthwhile companion read.
What this small-team path to GitOps adds up to
Notice what changed over those seven steps. Deployments stopped depending on who was free. Reviews became the doorway every change walks through. The repository turned into the honest answer to “what is running, and why?” None of it required the team to grow, and none of it happened in a single weekend — which is precisely why it held. Big conversions demand heroics and then quietly revert to old habits once the heroes are tired. Stepping through stages lets each one settle before the next begins.
For reference material at each stage — store choices, layout decisions, drift policies — this step-by-step GitOps reference covers the ground in far more depth than any single post can. The finish line, if there is one, is a quiet one: your friend’s team now ships on Tuesday mornings, before coffee, and the checkout page outage has become a story they tell new hires. That is what the method buys a small team — not speed for its own sake, but the specific speed that comes from never having to wonder what changed.
