Live data from Hacker News

Deploys at Slack

slack.engineering

31–40 of 139 posts

Re: Deploys at Slack

#31

It's always nice to see how other teams do it. Nothing too groundbreaking here but that's a good thing. I did notice the screenshot of "Checkpoint", their deployment tracking UI. Are there solid open source or SaaS tools doing something similar? I've seen various companies build similar tools but most deployment processes are consistent enough to have a 3rd-party tool that was useful for most teams.

> most deployment processes are consistent enough

Definitely disagree with this. I have never worked at two places with a similar enough deploy process that would benefit from a generic tool.

Re: Deploys at Slack

#32

Earlier quoted context omitted.

Seems reasonable to me? Better to deploy gradually in case the deploy is bad, right?

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).

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

#33
post #31

It's always nice to see how other teams do it. Nothing too groundbreaking here but that's a good thing. I did notice the screenshot of "Checkpoint", their deployment tracking UI. Are there solid open source or SaaS tools doing something similar? I've seen various companies build similar tools but most deployment processes are consistent enough to have a 3rd-party tool that was useful for most teams.

> most deployment processes are consistent enough Definitely disagree with this. I have never worked at two places with a similar enough deploy process that would benefit from a generic tool.

Sure, I see your point. I'd just like to see a pattern that works for most that could gain some traction. At the end of the day we're all trying to do the same thing (deploy high quality software), just in different ways. Deployment strategy shouldn't need to be a main competency of most teams.

Re: Deploys at Slack

#34
post #5

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. Or perhaps they do it exclusively with the free service tier, which is much more understandable.

Seems reasonable to me? Better to deploy gradually in case the deploy is bad, right?

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

#35
post #29
post #23

This link has now been reposted 6 times in the past two weeks: https://news.ycombinator.com/item?id=22816645 https://news.ycombinator.com/item?id=22729766 https://news.ycombinator.com/item?id=22801191 https://news.ycombinator.com/item?id=22784712 https://news.ycombinator.com/item?id=22720028 https://news.ycombinator.com/item?id=22806810

And yet it has only reached the front page once. Every article you see on top has been posted multiple times in order to get there. That is how online voting/aggregation systems work.

Every article you see on top has been posted multiple times in order to get there.

This isn't true at all, for the record.

Re: Deploys at Slack

#36
post #16

Do they use Kubernetes at Slack?

Doesn't seem like it based on > Instead of pushing the new build to our servers using a sync script, each server pulls the build concurrently when signaled by a Consul key change.

does that mean they are not even using containers?

Re: Deploys at Slack

#37
Fun to read, but there's a lack of detail here that I'd like to see. For example, this talks purely about code changes. However times a code change requires a database schema change (as mentioned above), different API's to be used, etc. In the percentage based rollout where multiple versions are in use at once, how are these differences handled?

Re: Deploys at Slack

#38

It's always nice to see how other teams do it. Nothing too groundbreaking here but that's a good thing. I did notice the screenshot of "Checkpoint", their deployment tracking UI. Are there solid open source or SaaS tools doing something similar? I've seen various companies build similar tools but most deployment processes are consistent enough to have a 3rd-party tool that was useful for most teams.

We (Gumroad) open sourced ours: http://github.com/gumroad/wilfred

Here's what it looks like: https://twitter.com/shl/status/1128039742308737024/photo/2

Re: Deploys at Slack

#39

Earlier quoted context omitted.

Seems reasonable to me? Better to deploy gradually in case the deploy is bad, right?

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'.

The gain is 1 syllable

Re: Deploys at Slack

#40

Fun to read, but there's a lack of detail here that I'd like to see. For example, this talks purely about code changes. However times a code change requires a database schema change (as mentioned above), different API's to be used, etc. In the percentage based rollout where multiple versions are in use at once, how are these differences handled?

I'm more curious about how DB rollbacks occur in situations where a PR changes DB and is then reverted.
Post reply on HN