IBM 的工程团队如何在整个开发生命周期中使用 Slack

无论 Thomas Lawless（IBM 的一位资深软件工程师）和他的团队在前一天取得了多大的进展，他们在每个工作日开始时都会检查是否有需要审核的代码。“这好像就是我们每天早上都在重新制定流程。”Lawless 说。

Lawless 负责监管 IBM 一些大型内部网络应用的生产、部署和交付。“我的工作范围涵盖了开发、持续集成、测试自动化、部署自动化和运维。”他解释说，“这意味着每一天我要和来自不同团队的 40 到 50 个人打交道。”

Lawless 的一项重要工作是引入开发技术和服务，以改进运维并加快交付。一年多以前，他开始与 IBM 内其他团队一起使用 Slack，把它作为一个沟通的枢纽，但他很快发现，Slack 也非常适合收集非人工通讯，比如系统警报和来自其他服务的通知。

Lawless 说：“我们有一个所谓的‘端到端交付管道’，覆盖了从源代码一直到生产部署的整个过程。现在，我们把 Slack 集成到了这个管道中的所有关键节点。”

使用 Slack 管理构建和部署流程

在 IBM，团队倾向于使用公共的 Slack 频道（例如 #development-team），这样团队成员可以公开讨论问题，其他团队的专家也可以轻松加入并给出自己的意见和建议。

团队频道包含团队成员发送的消息，也包含他们使用的很多应用发出的系统提醒。比如，当开发人员向源代码中提交用户故事以供审核时，系统会在团队的 Slack 频道中触发一条通知，让所有人知道有新的代码需要审核。审核者可以直接通过这条 Slack 消息进入系统审核代码。

“在我们使用 Slack 之前，开发人员必须找到他们觉得应该是审核者的那个人，然后给对方发邮件或发起一对一聊天。”Lawless 说。

将团队的整个工作流程贯穿于 Slack 中后，他们能够跟上进度。这是因为，每次有代码需要审核时，他们都会收到通知，然后可以直接在 Slack 中确认并开始处理。

围绕系统提醒集结团队，更好地进行事故管理

以下就是 IBM 一些常用的团队频道及其中出现的对话和通知类型：

• #help-services：收集 Pull Request (PR) 通知，以协助进行自动的代码同行审核，并在请求得到批准时提醒团队，让团队成员无需切换应用即可获取最新更新。团队还依赖 Jenkins/Travis CI 集成，在构建状态发生变化时获得通知。
• #help-deployments：当代码变更在进行自动化测试时，如果部署失败，团队成员会收到相应通知。
• #help-tasks：在批处理作业失败时发布通知。
• #starfleet-monitoring：用于运行时监控和事故管理，这里会推送来自 NewRelic、Splunk 和 PagerDuty 的通知。

Lawless 解释说，当 Slack 中显示失败或事故提醒时，相关的团队成员就会针对这个事故建立一个新的频道，他们可以在其中讨论可能的解决方案，并根据需要邀请其他专家加入。

问题解决后，团队会得到一份关于事故的完整记录，包括他们在寻求解决方案时讨论的所有文件、截图、错误消息和提醒。

“这个频道起到了一种审计跟踪的作用。”Lawless 说，“我们使用这些事故频道作为事后分析的基础，最大的好处是不用猜测，因为所有的历史记录都一览无遗。”

最近，Lawless 和他的团队开始使用 Slack 与他们使用的各种服务提供商进行交流。他发现，大多数公司都乐意在他们的团队之间共享一个私密的 Slack 频道，这样他们可以讨论可能遇到的问题和疑问，节省了大量来回沟通的时间。

减少额外步骤，带来工作效率的大幅提升

从编写和测试初始源代码一直到最终部署，Lawless 和他的团队已经将 Slack 集成到开发过程的每个阶段。现在，大家不用每天早上检查是否有新代码需要审核，而是可以从前一天停下的地方继续工作。

“每当我看到 Slack 集成时，我都会打开它。”Lawless 说，“它为我们提供了巨大的价值，可以帮我们省去工作流程中的很多步骤。”