Pragmatic Releasing | Hacker News Reader

Pragmatic Releasing

blog.algolia.com

48 pointsvvoyer5 comments

Meh. This works when you’re algolia and co and your “users” are developers. When your users are real users and you’re not dealing with web resources that can be live updated, a release is a big deal and shouldn’t be treated so blithely.

When we release a new version of a native desktop software, we are “owning” that release and taking responsibility for it. Our customers pay money for our products, and if someone (especially a new customer) we’re to download a broken build in that time, it will cause a much bigger headache than having to wait a bit for a release to go out.

There are two extremes, and this article switches between them: release early and break often, and release rarely but break nothing. For algolia to have shipped a broken release and have only one person that can release is the problem. Either a release is no big deal and everyone can release and it’s ok if a release is and, or a release is a really big deal and only select people can release to ensure the quality of releases.

The answer isn’t globally “make releasing easier,” it’s to decide which model best suits your company product, and embrace that. Either test your releases like crazy to make sure you don’t ship broken code, or make it easy and fast to fix a bad release.

Companies like Instagram/Quora have written about having multiple releases per hour. Basically, every 'git push' is a release if the tests pass. So, the model works for consumer companies to some extent (at least on the backend side).

Would be interesting to hear about the deployment practice of more mission critical products like AWS/GCP.

The Instagram android app was last updated 4 days ago, Facebook 5 days ago.

They could do similar automated updates to the apps, including publishing them, but they've clearly chosen the path of test thoroughly first, then release.

You’re referring to a mobile application that inherently has a slower release cadence - certainly for Apple with their verification process.

A web app can be released multiple times an hour if the business has confidence in its automated tests and release plan.

I have to say that I agree with most of your statements. I wouldn't be so radical about either "release fast and introduce bugs" vs "test thoroughly and have longer release cycles".

I think you could definitely see slow release cycles yet introduce bugs. By a matter of fact, I update my desktop software everyday to patch issues. In some environments like in Chrome, extensions get updated automatically. I agree that the end user experience as to be kept in mind.

I'm not encouraging neglecting quality in favour of speed of release. Quality definitely has to be taken into account. It then always comes down to how crucial it is for your code to not be broken, and what the impact of a given change could lead to.

In the end, like always, balance according to the context is key.

Reply on news.ycombinator.com