HackerTubewatch
Surprise me
Frame from ChatOps at GitHub - Jesse Newland Plays via YouTube's privacy-enhanced embed

ChatOps at GitHub - Jesse Newland

Rubyfuza
Talks
YouTube
2 HN users recommended this talk2 months2013–2021 score 2
Years with an HN recommendation, 2007–2026

The go-to reference for ChatOps, recommended for the idea of chat as a shared command line where teammates learn by watching.

Jesse Newland describes how GitHub uses Hubot, its chat bot, to run operations such as deployment, monitoring, graphing and provisioning from chat rooms. He explains how this improves shared awareness and remote work culture.

“There's a pretty good talk on "chatops" by the guys at GitHub[0].” (HN, 2015)

2 recommendations · 4 citations · Talks · intermediate · partly dated

6 Hacker News comments

From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.

@holman Nov 2013 Recommends
on HN thread How GitHub No Longer Works
Read more
Absolutely. As I mentioned, we have 150+ rooms that we chill in, and most of our day-to-day work practices are tied into chat. Mention someone's name in a room they're not present in and we send push notifications to their phone and desktop- works great to pull people in as needed, without needing to distract them with the noise of being in the room 24/7. Our ops team is particularly in deep with chat. Instead of siloing everyone's process off individually in SSH sessions, many operations happen in chat, so everyone can learn and help out when diagnosing problems. They've built some really fascinating tooling around the problems they face- if you're interested, check out @jnewland's talk on ChatOps: [this video]
How GitHub's ops team runs operations through chat
@jzelinskie Dec 2015 Recommends
on HN thread Slack Platform Launch
There's a pretty good talk on "chatops" by the guys at GitHub[0]. Basically, it provides a dialog around a "shared command-line" where developers from learn from each other by simply watching chat. I think it's more beneficial to distributed companies. However, my question for those using chatops is basically how do you keep the repository for the bot "tame"? It needs access to _everything_ if you want it to be useful, which means having lots of secrets exposed to the bot. [0]: [this video]
ChatOps as shared command line where developers learn by watching

Citations, criticism and jokes

@Rockslide Dec 2015 Cites it
on HN thread GitHub's Metal Cloud
There was also a talk titled "Chatops" about this specific thing if you want to learn more: [this video]
Talk on ChatOps
@EvanPlaice Jan 2016 Cites it
on HN thread Ask HN: What software would you pay for right now?
The DevOps approach: Just write a Slack plugin for all those things, if they don't already exist (they totally do tho). /s In all seriousness. Communication IS the baseline requirement for the super-app you speak of. The next requirement is making the platform talk to any data source. Slack does both of these things surprisingly well. Check this out: [this video]
Chat as a platform connecting data sources
@EvanPlaice Feb 2016 Cites it
on HN thread SSH: Best practices
Read more
3. Never grand direct SSH to access the the staging/production environment. Automate the build and deployment environment on a system that developers don't have direct access. Instead of pushing changes, the bot pulls a specified release branch, builds, tests, and deploys the code. All without human interaction. If malicious code were somehow introduced from a developer's environment, it would be recorded and reflected in the commit history. AFAIK, that's how GitHub manages deployments via HubBot. See [this video] . ----- To take things a step further, public-facing environments should be made immutable wherever possible. With the entire system being built and released as a whole. Docker alleviates some of the complexity and overhead but I think this space is where Unikernels have a lot of potential to shine. There's a very good talk about how the Wunderlist team used chaos and frequent destruction of their envronments to overcome fear and uncertainty here. [link] . Emphasis being placed on the the frequent disposal and recreation of environments rather than building long-running persistent environments. This setup probably won't work for long-lived systems (ex databases). In those cases, access via a transient environment like a USB bootable OS would be ideal to prevent persistent viruses/trojans. Ironically, the best current options are security-focused distros like KaliLinux that put a special emphasis on avoiding persistent state. Maybe one day soon we'll see an admin-focused
GitHub deploys via a bot rather than direct SSH
@sciurus Jan 2021 Cites it
on HN thread Improving how we deploy GitHub
Github is well know for doing chatops for everything . In fact, I think they may have invented the term. Here's a relevant talk from 2013: [this video]
Early talk from 2013 on GitHub's chatops

Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.

Keyboard shortcuts

/
Search
j k
Next / previous video
r
Surprise me
l
Like (video page)
w
Watch later (video page)
?
This help
Esc
Close