←back to thread

528 points sealeck | 2 comments | | HN request time: 0.533s | source
Show context
taylorlapeyre ◴[] No.31390879[source]
The main thing I want is pipelines - review apps, staging apps, and promotion to production, all integrated closely with GitHub, along with a slack integration that lets me do all of it in a public chatroom.

Until another service has all of this, we’re sticking with Heroku.

replies(6): >>31390948 #>>31390996 #>>31391072 #>>31391769 #>>31392684 #>>31393896 #
EqNoteqp ◴[] No.31390948[source]
I get the intention with Slack. I’ve never understood, except for the geek cred, pushing work into chat services. Github is open to the team too.

I hear complaints about chat distractions and see engineers create those distractions. I’m at a loss why we want to do that to ourselves?

Nevermind it’s one more pipeline for messages to lost in. It’s needless complexity and configuration too.

replies(3): >>31391169 #>>31391616 #>>31392565 #
bri3d ◴[] No.31391169[source]
The main reason is to use a chat solution is as a unified ledger / single pane of glass. Silly as it is, there isn't really a better solution out there for "integrate all of my third-party deploy, CI, build, etc. status updates in real time, in one place." Sure, someone can click into GitHub, but if you use another service to deploy into, does GitHub pipe the status of that service into your dashboard? How about error logs and alerting, do they go there? If there's a customer incident, does the trust site status show up as well?

On Slack and other chat solutions, it's possible to set up a #operations style single-pane-of-glass channel with deploy notifications, error alerting, and customer communication platforms all pushing to the same place. If an incident occurs, engineers, product, support, etc. can all collaborate around what's going on in real-time without needing to ask "hey has someone updated the trust site yet?" or click into 10 different tabs.

It's honestly pretty good when it works well and really bad and noisy when it doesn't, but it has a place.

Non-engineering are usually in Slack too, which really helps when support, product, or the field need quick answers to easy questions like "has this commit been deployed yet today?"

replies(1): >>31391226 #
1. tshaddox ◴[] No.31391226[source]
Perhaps for looking back to see the history of things, a unified ledger is convenient. But as a notifications/alerts solution it’s terrible because it essentially guarantees that the signal to noise ratio will be incredibly low.
replies(1): >>31392068 #
2. mulmboy ◴[] No.31392068[source]
This just depends on how disciplined you are. We use a system where backend errors are logged to slack, and then we treat addressing the source of the errors as an immediate priority. Keeping the SNR high is a priority. Plus generally being very selective about what goes into the channel.