Release every week without breaking things

DevOps is the way of working that makes releasing software routine instead of risky. It joins the people who write the software with the work of running it: building, testing, releasing, watching and fixing, done the same way every time by tools rather than from memory.

In a large company there may be a whole team for this. In a small or mid-size business there is usually nobody: a few developers write features, and one of them deploys late at night by following steps only they know. Nothing is wrong with the people. What is missing is the system around them.

Our DevOps work builds that system. It is a set of automated tests, a release pipeline, copies of your app to try changes on, monitoring that tells you when something is off, and servers described as code. None of it is exotic. The value comes from having all of it, working together, on every change.

Smaller releases are easier to check, easier to explain and easier to undo. A monthly release bundles dozens of changes. If something breaks, nobody knows which change did it, and undoing the release also undoes the fixes customers were waiting for.

A weekly release holds a handful of changes. Each was reviewed and tested on its own, the people who made it still remember the details, and if one misbehaves it can be switched off or rolled back without losing the rest. Fixes reach customers in days instead of waiting for the next big night.

Weekly is a rhythm we agree with you, not a target to chase. Some teams settle on releasing whenever a change is ready; others keep a fixed day so support and sales know what is coming. What matters is that releasing stops being an event.

Start by protecting the few things that must never break. For most businesses that means signing in, searching and ordering, taking payment by UPI or card, raising invoices with the right GST, sending order and delivery messages, and the exports your accountants depend on, such as the daily file into Tally.

We write automated tests for those paths first, end to end, the way a customer or a staff member uses them. A failing test stops the release before a single customer sees the problem.

Chasing a test for every line of old code is slow and rarely worth it. Tests grow where changes happen: each new feature arrives with its own, and each bug that escapes gets a test so it cannot return.

Every change takes the same path from a developer’s branch to your customers. The pipeline builds the code once and keeps that build, so what was tested is exactly what goes live.

Then come the checks: unit tests, end-to-end tests on the paths that earn money, code style, and a scan of every library the app uses for known security holes. A change that fails any of them goes back to its developer with the reason attached.

A change that passes is deployed to staging automatically and tried there. Releasing to production is then one approval in GitLab or GitHub, by someone you choose. The pipeline tags the release, records what changed and who approved it, and posts a short note to your team’s chat.

People who know the work should see a change before customers do. Staging is a copy of your app with realistic data, with personal details such as names, phone numbers and PAN masked, so it behaves like the real thing without exposing anyone.

For bigger changes, each one gets its own preview link. The owner of the feature, a sales head or the accounts team, opens it on their phone and says yes or no before it is merged.

Feature switches separate putting code live from turning a feature on. New code can go out switched off, be turned on for your own staff, then for a small share of customers, then for everyone. If the numbers look wrong, the feature is switched off in seconds without a new release.

Database changes are where risky releases hide, so we make them in small steps. Renaming a column or splitting a table in one go breaks the running app for anyone mid-task, and makes rolling back the code useless.

Instead, each change is split into steps that old and new code can both live with. First the new column is added and filled. Then the code starts writing to both. Then it reads from the new one. Only when nothing uses the old column, often a release or two later, is it removed.

Every migration is tried first on a copy of the live database at full size, so a change that would lock a busy table for minutes is caught on a quiet copy, not on a Monday morning. A backup is taken before each release that touches data.

You should hear about a problem from your own systems, not from a customer. We set up error tracking in the app, uptime checks from outside your network, logs gathered in one place, and dashboards for speed and errors.

We also watch the signals your business cares about: orders per hour, failed payments, messages not delivered, invoices stuck. A release that quietly stops a payment method is caught by these numbers even when no error is thrown.

Alerts are tied to releases, so the alert itself says what went out and when. We keep alerts few and meaningful, because a team that receives fifty a day learns to ignore all of them. Someone is named for each alert, with hours agreed in India time and cover for your busy seasons.

A release that cannot be undone should not go out. Every release keeps its build, so going back to the last good version is a single command or a button in the pipeline, and because database changes come in steps, the older code still works with the data.

The rule is simple: if a release looks wrong, roll back first and investigate second. Customers get the working version back while the team finds the cause without pressure.

Afterwards we write a short note on what happened, why the checks missed it and what changes. Usually the answer is one more test, one more alert or a smaller next release. The note blames no one; its job is to make the next release safer.

Security checks run on every change, so they stop being a once-a-year event. The pipeline scans libraries for known weaknesses, looks for passwords and keys accidentally committed to code, and checks container images before they are deployed.

The pipeline itself is guarded. Its keys can deploy and nothing more, production approvals belong to named people, and every action is logged. Passwords live in a secrets store, never in the repository.

For businesses with rules to meet, such as RBI directions for lenders and payment companies or HIPAA-style privacy for health data, this record of who changed what and when is exactly what auditors ask to see. Deeper checks, such as penetration testing before a major launch, are planned as their own step.

When the set-up is done, your team should be able to run it without us. Everything lives in your repositories and your cloud accounts: the pipeline, the infrastructure code, the alerts and a short written guide for each routine job, from adding a new environment to rolling back a release.

We join the first weekly releases side by side with your developers until the routine feels ordinary, then step back. Some businesses keep us on to watch alerts, keep the pipeline fast and update the tools each month; others call only when they add something new. Either way, the releases keep going out every week.