A SaaS Release Process for Weekly Releases Without Regressions

To release a SaaS every week without regressions, fix the calendar and gate every step. Merge small changes behind feature flags all week. Cut a release candidate on a set day, run the full automated regression and a short exploratory pass on staging, then ship early in the week with an approval gate. Smoke-test production straight after, and roll back by rule, not by debate.

If you would rather have the process set up and run for you, see how RAITHub would test this near the end. Everything before that is the method, written so a team of two to ten engineers can adopt it without outside help.

Why do weekly SaaS releases keep breaking things?

Usually not because the team is careless, but because the release has no shape. Changes arrive on the main branch until the last minute, nobody knows exactly what is in the release, and the only test is "it worked on my machine and in a quick click-through". The same root causes come up again and again:

• Big, late merges. A week of work lands on the day of release, with no time to test it together.
• No release candidate. What was tested on staging is not exactly what ships.
• Schema changes tied to code changes, so a deploy and a migration must succeed together or both fail.
• No post-deploy check, so customers become the smoke test.
• No rollback rule, so the team argues for an hour about whether the bug is "bad enough".

The longer version of this diagnosis is in every release breaks something. This guide is the process that replaces it.

What does a weekly release calendar look like?

Pick days and keep them. Predictability matters more than which day you choose. This is one workable calendar for a team that releases on Tuesday:

Day	What happens	Gate
Wednesday to Thursday	Small pull requests merge to main behind feature flags	Pull request checks pass; one reviewer approves
Friday morning	Cut the release candidate: tag main, deploy that exact build to staging	Full automated suite green on the tagged commit
Friday to Monday	Exploratory pass on staging; product owner checks new features against acceptance criteria	No open blocker or critical bugs
Monday	Fix blockers on main and cherry-pick into the release branch; write release notes	Every cherry-pick re-runs the suite
Tuesday morning	Deploy to production with an approval gate; run smoke tests; turn on flags gradually	Smoke tests green; error rate steady for an agreed window

Tuesday is a choice, not a rule. What matters is releasing when the people who can fix a problem are working for the next several hours. Avoid releasing at the end of anyone's working day. The branch-and-cherry-pick pattern comes from Google's release engineering practice: branch from the mainline at a specific revision, submit fixes to the mainline, then cherry-pick them into the release branch (Google SRE book, Release Engineering). It gives you exact control over what ships.

How do feature flags make weekly releases safer?

They separate deploying code from releasing a feature. Unfinished work can merge to main every day, switched off, so there is never a big late merge. A finished feature can ship in Tuesday's release but turn on for internal users first, then for a share of customers, then for everyone. If it misbehaves, you turn it off without a deploy.

Two rules keep flags from becoming their own mess. Give every flag an owner and a removal date, and remove the flag and its old code path within a release or two of full rollout. The design choices, from a simple database table to a hosted service, are covered in feature flags for SaaS.

Which CI gates should every change pass?

Every pull request runs static checks, unit tests, API tests and the tagged critical end-to-end journeys. The release candidate runs everything, including the slower suites. If you are not sure how to split tests across those layers, see the test pyramid for a SaaS.

Database changes need their own gate, because they are the change most likely to break a release that passed every test. Ship schema changes in an earlier release than the code that depends on them, using expand-and-contract, and replay every migration on an empty database in CI. The method is in zero-downtime database migrations for SaaS. On Sundor Skin, a B2B platform RAITHub built, CI replays all 76 migrations on every change, as part of 530+ automated tests.

How do you gate the production deploy?

Deploy only a tagged build that passed staging, and require a named person to approve it. GitHub environments support this. Required reviewers let a listed person or team approve jobs that use the environment (up to six), and deployment branch rules restrict which branches and tags can deploy to it (GitHub: deployments and environments). Check your plan: the same page notes that on GitHub Free, Pro and Team, required reviewers and wait timers are only available for public repositories.

# .github/workflows/release.yml
name: release
on:
  push:
    tags: ['v*']
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npm run test:all
  deploy-production:
    needs: verify
    runs-on: ubuntu-latest
    environment: production   # required reviewers + tag rule set here
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh "${{ github.ref_name }}"
  smoke:
    needs: deploy-production
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test --grep "@smoke"
        env:
          BASE_URL: https://app.example.com

Replace deploy.sh and the URL with your own. The point of the shape is that production only ever receives a tag that passed the full suite, someone approved it, and a smoke run follows automatically. The detail of what smoke tests should check is in regression testing after every deploy.

What should the release checklist include?

Keep it short enough that people actually read it. Ten lines is plenty:

1. Release candidate tag and the list of pull requests in it
2. Full automated suite green on that tag
3. Exploratory pass done on staging, with notes on what was tried
4. Acceptance criteria checked by the product owner for each new feature
5. Migrations in this release are additive only, or are the planned contract step
6. New flags listed with their default state and owner
7. Release notes written for customers and for support
8. Rollback method confirmed: previous build ID ready
9. Someone on watch for the agreed window after deploy
10. Status page and support team told about anything customers will notice

For the customer-facing side of incidents, see SaaS SLAs, uptime and status pages.

When should you roll back, and who decides?

Decide before the release, in writing. A typical rule: if smoke tests fail, or the error rate or a key business event (sign-ups, payments, the core action) moves clearly the wrong way within the watch window, the person on watch rolls back first and investigates second. No meeting needed. Roll back the code by redeploying the previous build. Because schema changes in a release are additive, the old code still works against the new schema, which is what makes a fast rollback safe.

If the bug is in a feature behind a flag, turning the flag off is a rollback too, and usually faster.

How do you know the process is working?

Track a few of the DORA software delivery metrics. DORA defines change fail rate as the ratio of deployments that require immediate intervention following a deployment, and failed deployment recovery time as the time it takes to recover from such a deployment. It also tracks deployment frequency and change lead time (DORA metrics guide). A working weekly process holds deployment frequency steady, pushes change fail rate down, and makes recovery a matter of minutes because rollback is rehearsed. Add one number of your own: bugs reported by customers in the week after each release.

How long does it take to set this up yourself?

For a team that already has CI and some tests, about one to two weeks of a senior engineer's time: a release calendar, tagging and branch rules, the environment gate, a smoke set of five to ten tests, a flag system and the checklist. The main risk of doing it yourself is the exploratory and regression work after setup. In a busy week, developers skip testing their own release, and the process quietly turns back into "merge and hope".

Buy, build or hire?

Option	What you get	Choose this when
A tool or SaaS testing platform	Hosted test runs, release dashboards, visual checks	Your process is sound and you only need better tooling for it
Freelancers or crowdtesting	Extra manual testing before a release	You need a one-off check before a big launch; weekly use is hard to coordinate
An in-house QA hire	One person who owns the release candidate check every week	You can keep a tester fully busy and have someone to manage them
A managed QAaaS team	A provider-managed team that runs the regression and exploratory pass each week and maintains the suite	You want the weekly check done reliably without hiring or managing testers

Why RAITHub for this

RAITHub ships its own products through gated pipelines: 1,024 tests on PropDesk, 530+ on Sundor Skin, 750+ on TheSkinProof (the founder's own venture, not a client) and 400+ on this website. RAITHub's QA offer covers both halves of a weekly release: the automated suite through QA and test automation, and the human half through manual and exploratory testing and UAT support. If you are still building the product itself, the SaaS development service includes this release process from the first week.

When you don't need us

• You release less than monthly to a few customers. A checklist and a staging click-through may be all you need.
• You already have a QA lead who owns the release candidate. Give them the calendar and gates above.
• You need a certified test lab or a compliance attestation. RAITHub is not SOC 2 or ISO 27001 certified.

How RAITHub would test this

• Scope: set up the calendar, release branch and tag rules, the production approval gate and the smoke set; fill gaps in the automated regression; run the exploratory pass on each release candidate.
• Ways to buy it: a fixed-price one-off pre-launch QA audit, a monthly QA plan that covers each weekly release, or a dedicated QA team that RAITHub manages and bills monthly. Testers stay under RAITHub's management; this is not staff augmentation.
• Timeline: the setup is fixed in the written quote after the audit; the weekly testing then runs on the monthly plan.
• What you receive: workflows and tests in your repository, the release checklist and runbook, a written report per release candidate, IP assigned to you and an NDA as standard.
• Next step: a free 15-minute technical audit, then a fixed written quote.

See how the plans work on the QA as a service page, or book the free 15-minute technical audit.

Documentation checked on 7 October 2026.

Frequently asked questions

What day of the week should a SaaS release?

Any day when the people who can fix a problem are working for the next several hours. Many teams pick early in the week and avoid the end of the working day or the day before a weekend.

Do we need a release branch if we deploy from main?

Not always. A tag on main is enough if fixes are rare. A release branch helps when you need to ship a fix into this week's release without also shipping everything merged since the candidate was cut.

How long should the release candidate sit on staging?

Long enough for the full automated suite, an exploratory pass and the product owner's acceptance check. For a weekly cadence, one to two working days is a common window.

Should database migrations ship in the same release as the code that uses them?

Prefer not. Ship additive schema changes in an earlier release, then the code that uses them. That keeps rollback safe, because the previous build still works against the new schema.

Are feature flags enough to replace testing?

No. Flags limit who sees a change and make it quick to switch off. The code behind a flag still runs in production and still needs tests, and the flag-off path needs testing too.

What is a good change fail rate for weekly releases?

Lower is better, and the trend matters more than the number. Track the share of releases that need a rollback or hotfix, and add a test or gate after each one so the same failure cannot repeat.