Anyone who has planned a full day of sightseeing in Mumbai knows the routine: you decide the neighbourhoods the night before, you agree who carries the tickets, and you accept that the local train timetable — not your mood — decides when you actually move. Running a website’s infrastructure well turns out to rhyme with that. GitOps takes the timetable idea seriously: you write down how everything should be configured, keep that description under version control, and let an automated agent bring the real system back in line whenever the two disagree. No heroics, no guessing which server has which setting, and no 11 pm change made from someone’s phone in an auto-rickshaw.
This checklist is for small teams who publish a lot and administer a little — city guides, event listings, that sort of thing. Work through it in order; each stage assumes the one before it is done. If you want the full technical backing for any line, xOps School’s GitOps guide goes much deeper, labs and runbooks included.
Stage One: Decisions to Make Before Installing Anything
Skip these and you will redo work later. Tooling is the easy part; the arguments are all in the decisions, and every one of them is cheaper to have before an install than after. They are judgement calls, not purchases:
- Where the description lives. A Git repository is the usual answer, though a versioned bucket or an OCI registry also qualifies if that fits your team better.
- How the files are arranged. Most groups settle on one repository with clear top-level sections — cluster definitions, shared infrastructure, tenant bits, application configs.
- The topology. One central hub that reaches out to every environment, one agent per cluster, or a hub with lightweight agents that pull from it. Small teams usually start with the first option and grow into the third.
- How secrets stay out of the repository. Plain-text passwords in Git are a resignation letter waiting to be written. The usual fixes answer to names like SOPS, Sealed Secrets and the External Secrets Operator, and each reaches the same goal by a different route — encrypted values in the repo, or live lookups from a vault at run time. Choose one, then write down the reason.
- Your drift policy. Decide in advance what happens when live reality stops matching the written one — which differences get rolled back, which get allowed, which raise an alert.
Stage Two: The First Week of Real GitOps Work
Week one is about trust, and trust is built on small controlled demonstrations:
- Bootstrap the reconciler and — this is the elegant part — have it manage its own installation. From that moment the tool upgrades itself the same way it upgrades everything else.
- Migrate one namespace at a time, with destructive cleanup switched off. Prune stays disabled until you have watched the system behave for a while.
- Run the first fortnight on manual sync approval, even if it feels slow. Reading each diff is how a team learns what the tool will do when it is finally allowed to act alone.
- Deliberately make an out-of-band change in a safe environment and watch the agent notice and correct it. If that demonstration does not convert the sceptics on your team, nothing will.
One expectation to set early: the loop is periodic, not instant. Argo CD, for instance, polls on a roughly two-minute cycle with added jitter, and a webhook only makes the next poll arrive sooner. Wire one up if you like, but protect it with a shared secret, since the endpoint itself will turn away nobody — and whatever you do, do not promise anyone “real time”.
Stage Three: Habits That Keep It Healthy After a Month
Once the basics hold, maintenance becomes calendar work. Upgrade the reconcilers on a schedule and treat those upgrades as urgent when they touch anything production-critical. Rotate the signing keys and credentials on a schedule too, not when someone remembers. And once a quarter, rebuild an environment from the repository alone; the drill proves the description is complete instead of merely plausible. Teams that skip the drill usually discover missing pieces during an actual outage, which is the most expensive possible moment for that discovery.
A few stumbles account for most failed first attempts, and all of them are avoidable:
- Turning on every feature in week one, then being unable to say which one caused the strange behaviour.
- Keeping one beloved server configured by hand, “just in case” — which quietly becomes the only machine that actually works.
- Letting drift alerts pile up unread until the team stops trusting them. An alert nobody answers is worse than no alert, because it teaches everyone to ignore the channel.
- Skipping the quarterly rebuild because the last three passed. The fourth quarter is when the undocumented dependency shows up.
Your GitOps Invariants, on a Single Card
Long-running programmes tend to distil a handful of rules that never bend. Five worth adopting come straight from practitioners who have run this at scale:
- Exactly one path to production, and it runs through a reviewed change.
- No mutable references anywhere — no floating version tags, no charts pinned to “whatever is newest”.
- Reconcilers get least-privilege access, never blanket admin rights.
- Deletion is guarded; anything destructive needs an extra deliberate step.
- Data stays out of the repository. Git holds configuration, never customer records or database contents.
Print the five on one page. When a shortcut is proposed at 6 pm on a Friday, the card answers for you.
A 30/60/90 Pace Worth Copying
Rome, and all that. The first month is paperwork and a staging experiment: an architecture decision record, a non-production environment under the new model, syncs applied by hand, alerts whenever something drifts. The second month turns on automated sync for staging, moves secrets into the tooling you chose earlier, locks down tenant permissions, rehearses the emergency override, and — the satisfying bit — deletes the standing cluster credentials from the old CI system. The third month brings the first production services under automated sync, starting deliberately with the low-risk ones, then adds deletion guards, a small status dashboard, and the first full rebuild drill. Three months, and the site’s plumbing stops depending on anyone’s memory. Put the dates in a shared calendar so the pace survives holidays, staff changes and monsoon distractions alike.
Why a Mumbai Guide Cares About Any of This
Because readers do not wait. Traffic to a city site arrives in spikes — a long weekend, a festival, a sudden rain warning — and each spike is the worst possible time for a misconfigured server. The pages in our roundup of the must-visit places in Mumbai get their heaviest load precisely when everything else is busiest. Picture the scene: the skies open at 5 pm, half the city starts searching for indoor plans, and your listing pages slow to a crawl because of a config change someone made by hand that afternoon. A written, enforced, self-correcting setup is what stands between that afternoon and an apology post.
The publishing side benefits too. A team that already plans content the way it plans a route — a complete sightseeing trip laid out step by step, or a full guide to the city’s experiences, heritage and food — will recognise the shape of the checklist above immediately. Write the plan, share the plan, let the plan drive. The servers deserve the same courtesy you give a day’s itinerary, and with GitOps they finally get it.
