
Pragmatic Releasing - vvoyer
https://blog.algolia.com/pragmatic-releasing/
======
ComputerGuru
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.

~~~
jatins
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.

~~~
EwanToo
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.

~~~
rosswilson
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.

