News for hackers. Stuff that matters.
Re:Deploys at Slack by walrus01 on Wednesday April 08, 2020 @05:04PM (#22817119)
<sarcasm>

How nice of them to volunteer 2% of their paid customer base as "canary" without them specifically opting in to it, or perhaps even being aware.

</sarcasm>

Or perhaps they do it exclusively with the free service tier, which is much more understandable.

Re:Deploys at Slack by deadbunny on Wednesday April 08, 2020 @05:26PM (#22817351)
Anecdotally I usually see slack changes in my free tier channels a good week before paid tier ones so it wouldn't surprise me.
Re:Deploys at Slack by nuclearnice1 on Wednesday April 08, 2020 @05:33PM (#22817414)
2% chance of being canary 20% chance it breaks Expected 15 minutes to roll back

Expect 3.6 seconds of outage per user outage per release.

It’s fine.

What I’d like you to get behind is disabling Windows Update. THAT thing is a menace.

Re:Deploys at Slack by friend-monoid on Wednesday April 08, 2020 @05:08PM (#22817155)
Seems reasonable to me? Better to deploy gradually in case the deploy is bad, right?
Re:Deploys at Slack by dingaling on Wednesday April 08, 2020 @05:50PM (#22817573)
Tangential, but why do companies continually misuse verbs as nouns?

Nothing is gained by saying 'deploys' instead of 'deployments' but instead confusion can be introduced.

See also ' what is the ask' and 'minimum spend'.

Re:Deploys at Slack by vpzom on Wednesday April 08, 2020 @06:00PM (#22817660)
The gain is 1 syllable
Re:Deploys at Slack by toomuchtodo on Wednesday April 08, 2020 @05:10PM (#22817174)
If the users are aware and consent to being beta testers, versus what’s already likely stable (caveat being when you’re rapidly pushing out a hotfix because your last deploy broke something).
Re:Deploys at Slack by copecopecope on Wednesday April 08, 2020 @05:14PM (#22817226)
At some point a new build needs to roll out to production. There's always going to be some risk that something goes wrong, so better to test with 2% of the population initially rather than 100%. By then, the build has already gone through integration tests/dog-fooding, so if something goes wrong in the canary phase, it's generally due to some production environment configuration issue.
Re:Deploys at Slack by toomuchtodo on Wednesday April 08, 2020 @05:15PM (#22817244)
Not disagreeing, simply stating users should be aware and get a say (an option would be fine to opt in to early release access), especially if they’re a paying customer.
Re:Deploys at Slack by copecopecope on Wednesday April 08, 2020 @05:22PM (#22817308)
I hear where you're coming from, but from my experience, the canary phase usually lasts less than an hour. And the traffic is usually split randomly, so the same 2% of users aren't at elevated risk for every deployment. I don't know how Slack does it, though.
Re:Deploys at Slack by paxys on Wednesday April 08, 2020 @05:45PM (#22817536)
They aren't beta testers. They are still getting the real production build, just in the first step of a phased rollout. Beta, pre-release etc. have a very different meaning.
Re:Deploys at Slack by friend-monoid on Wednesday April 08, 2020 @05:11PM (#22817192)
Link doesn’t work for me right now so I haven’t read the article, but usually beta testing precedes canary deploys. Maybe this is different.
Re:Deploys at Slack by toomuchtodo on Wednesday April 08, 2020 @05:12PM (#22817201)
If it’s canary, you don’t trust it fully, no? Tests can pass and you still end up munging data or the user experience.
Re:Deploys at Slack by IneffablePigeon on Thursday April 09, 2020 @07:46AM (#22821610)
Do you ever "fully" trust any software before it's been released to its final environment and run under load? I don't.

The idea isn't that you release less-tested software because you have the canary as a safety net. The idea is that you put in place all of the other practices you would anyway to minimise the likelihood of bugs and mistakes, and then you add a canary rollout as one extra layer of protection to mitigate the damage of anything you missed.

I would look at it as 98% of the users getting an even more reliable experience than they would otherwise (per release; everyone benefits over time), rather than 2% being given a worse experience. The alternative is just that everyone is in the "canary" release and everyone has to immediately use the release you "don't fully trust".