Hacker News Reader

Comment by jarm0 | Hacker News Reader

I agree that things could have been done better in many ways. However, as explained, it is a legacy application, which does not see any active development nowadays and it would just not make sense to build such a robust QA. This particular app have been written long time ago by another company and there's not even simple unit tests. That's the hard truth. But still, even as complex setup as you have, there's still going to happen mistakes and the real problem is that there is no way to pull-back/cancel/rollback release.

How would staged roll-out help in this situation for all customers? When end-user gets the faulty version of the app, does he/she have a way of getting the non-faulty version somehow?

View on HN

Unfortunately, as you noted, the game is rigged and you have to play within the sandbox provided. With that, and as you also noted, your testing simply needs to be better, especially since this is a customer-facing app and not an app that's solely used internally. As for dealing with the rollout when a serious bug is now in production, if you didn't roll out your app to 100% of the user base you could halt the roll out so it wouldn't affect any more customers. Then, while far from ideal, you could ask affected customers to uninstall the app and then reinstall it, and the newly installed version would reflect the previous version of your app.

A-ha - good tip about roll-out, uninstall & install. Was not aware of that possibility. But yeah, it's still a hack and there should be a better way - just let me delete/cancel latest release even if roll-out is 100% for whatever reasons.

About better testing - there's always room to improve testing, but no way it's going to happen with a legacy application where no active team is assigned. Only these irregular updates mainly forced by Google are done. Unfortunately.

building a business on any big vendor (google, apple, amazon, microsoft, etc) without at least making sure these risks are shared with the client seems like a fast way to run into these costly overtime problems.

Rigged seems a bit extreme. They had to make a few changes to keep things up to date. That they tripped over this small hurdle and went tumbling down the stairs doesnt change that it's a small hurdle.

Perhaps. I meant it more in the context of the Google Play Store policies as a whole, and they are voluminous, and not just this specific case.

Just to add, even if you do not change anything at all, you will spend many hours just getting the build environment up to snuff if it hasn't been touched in over a year. Gradle, the plugins (android, crashlytics, etc), the build.gradle DSL, dependencies ... its quick bit rot.

Android as an OS does not support rollbacks. It can only upgrade apps in monotonically increasing `versionCode`s. The simple reason is that client side data may have been upgraded by a newer release to a format that is now incompatible with the old version. Sqlite databases follow the same policy.

This is well-known to anyone who has been doing Android development for a while.

Totally understand that a roll-back is more complex, but it doesn't explain why pulling back/pausing/deleting/yanking a release is not possible either - customers who got the newest faulty release can uninstall & install to get the previous version back (no need to worry about incompatibilities here) and the ones who did not get the updated version yet can stay using the old one until a new fixed version will be released.

This is exactly what staged rollouts are for. The author ignored that best practice. You can halt any release as long as it is in progress. Once you mark it complete (defined as rolled out to 100%), you can’t roll it back.

Each track in Google Play (alpha, beta, canary, prod) can hold up to one release at a time. It would get really confusing if it allowed more than one. And with the other rollout safeguards provided decelopers, it’s quite possible and very easy to do exactly what you’re asking for.

"may" is the reason why not supporting rollbacks at the OS level is baddesign

> and it would just not make sense to build such a robust QA

Well since it broke, it kinda of would have made sense.

> This particular app have been written long time ago by another company and there's not even simple unit tests

He didn’t do a simple smoke test.

> it would just not make sense to build such a robust QA.

Well that's a lesson you won't need to learn twice, isn't it?

It's true that in the future I would do some more thorough testing, but never-ever for this legacy application can I build a bullet-proof automated testing solution - there will not be a budget for that for sure. However, even with a fancy solution mistakes will happen and you still can't stop release propagating. It's just a matter of time when it happens.

"A bullet-proof automated testing solution" isn't needed for the type of problem you describe. Anything that logs in (including a human on a real device) would catch it even if it does nothing else.

Exactly. It’s a poor excuse that the author didn’t even try to log in to the app with the newest version.

Reply on news.ycombinator.com