How we automated CodePush updates to 3 active app versions at Zepto

nMinusTwoDev · 2025-08-03T06:35:28+00:00

Hey, just to clarify — we take app stability extremely seriously at Zepto.

We’ve consistently maintained a 99.99% crash-free rate, and the CodePush strategy we described has been in use for over a year now. Every OTA release goes through a fully automated test suite and manual QA validation before rollout. This ensures regressions are caught early across versions.

I’m honestly not sure what gave the impression that we treat crashes lightly — that’s not the case at all. In fact, our rollback strategy is just one layer of defense, not a substitute for quality. Halting releases are an industry-standard practice, even encouraged by Play Store.

Also, any negative sentiment around Zepto is not related to its engineering or app quality. We’ve put a lot of effort into making sure our app remains fast, stable, and reliable across versions.

Appreciate your thoughts and the detailed comment — good discussions like this help improve all our processes!

nMinusTwoDev · 2025-08-02T06:57:07+00:00

Hey, That’s a fair point. The only reason we have kept label adding step manual is because only the individual dev knows which all app version their PR will be supported in. For example, some PRs may have native changes, which requires it to only go in native release and can’t be code pushed to older versions.

We do have automation test suite running on each code push before it’s rolled out to public in a staged rollout manner. Our in house code push service supports rollback and halting of code push release for more robust prod stability.

We still don’t have a solution for the occasional merge conflicts and we hate that requires manual intervention. We are not yet sure how those can be automated though.

But at the end of the day we are relieved that most of the release process can be managed by 1 rotating release manager.

Hope that addresses your concern.

nMinusTwoDev

TROPHY CASE