無論 IBM 的資深軟體工程師 Thomas Lawless 或他的團隊在前一天取得了多少進展，他們每天開始工作的第一件事就檢查是否有程式碼需要審查。他說：「感覺我們每天早上都在重複這個流程。」
Lawless 負責監督生產、部署和交付 IBM 一些最大的內部網路應用程式。他說明「我的工作範圍涵蓋開發、持續整合、測試自動化、部署自動化和營運，這代表我每天都會與40 到 50 位來自不同團隊的人員一起工作。」
「我們有所謂的「端對端交付管道」，整個流程從原始碼開始一直到生產部署，」Lawless 說。「而且現在我們已經將 Slack 整合到這個流程的所有關鍵里程碑中。」
Lawless 的一項主要工作是引入開發技術和服務，以改善營運並加快交付速度。一年多前，他與 IBM 內部的其他團隊開始將 Slack 作為團隊通訊中樞，但他很快發現 Slack 對收集非人類通訊 (例如系統快訊和來自其他服務的通知) 也非常有用。
「我們有所謂的「端對端交付管道」，整個流程從原始碼開始一直到生產部署，」Lawless 說。「而且現在我們已經將 Slack 整合到這個流程的所有關鍵里程碑中。」
在 Slack 中管理建置和部署流程
在 IBM，團隊傾向使用公開的 Slack 頻道 (例如 #development-team)，這樣團隊成員可以公開討論問題，且其他團隊的專家也能輕鬆加入並提供意見。
團隊頻道包含來自人員的訊息,以及他們所使用的多個應用程式的系統快訊。例如，當開發人員提交了一個使用者故事以進行原始碼審核時，系統會在團隊的 Slack 頻道中觸發通知，讓大家知道有新的程式碼需要審查。然後，審查者可以直接從該 Slack訊息中進入系統審查程式碼。
「在我們使用 Slack 之前，開發人員必須找到他們認為應該負責審查的人，然後傳送電子郵件給對方或與對方進行一對一聊天，」Lawless說。
透過 Slack 進行團隊工作流程，他們可以保持進度，因為他們會在需要時收到個別程式碼審查的通知，並能直接在 Slack 中確認並著手處理這些事項。
圍繞系統快訊召集團隊，以更好地管理事件
這裡快速介紹一些 IBM 的熱門團隊頻道，以及這些頻道中常見的對話和通知類型：
#help-services:收集提取請求 (PR) 通知，以促進自動化同儕程式碼審查，並在請求獲得核准時通知團隊，讓團隊成員無需切換應用程式即可獲取最新更新。團隊還依靠 Jenkins/Travis CI整合，在組建狀態發生變化時通知團隊。#help-deployments：當程式碼變更通過測試自動化時，團隊成員會收到部署失敗的通知。#help-tasks：當批次處理工作失敗時發布通知。#starfleet-monitoring：對於執行階段監控和事件管理，來自 NewRelic、Splunk 和 PagerDuty 的通知將推送到此處。
「該頻道起到了稽核追蹤的作用，」Lawless 說。「我們將這些事件頻道作為事後分析的依據，最棒的是大家再也不必猜來猜去，因為我們有完整的歷史記錄。」
Lawless 解釋說，當 Slack 中出現有關失敗或事件的快訊時，相關團隊成員會針對該事件建立一個新的頻道，他們可以在該頻道中討論潛在的解決方案，且任何成員都可以根據需要邀請其他專家加入。
問題解決後，團隊最後會獲得整個事件的記錄，包括在解決問題過程中討論的所有文件、截圖、錯誤訊息和快訊。
「該頻道起到了稽核追蹤的作用，」Lawless 說。「我們將這些事件頻道作為事後分析的依據，最棒的是大家再也不必猜來猜去，因為我們有完整的歷史記錄。」
最近，Lawless 和他的團隊開始使用 Slack 來與他們所用各種服務的提供者聯繫。他發現大多數公司都樂意與團隊共用私人 Slack 頻道，這能方便他們討論問題和疑問，進而節省大量來回溝通的時間。
減少多餘的步驟能大幅提高生產力
Lawless 和他的團隊已將 Slack 整合到開發程序的每個階段中，範圍從編寫和測試初始原始程式碼一直到最終部署。所有人都不必再花早上的時間檢查要審查的新程式碼，而可以直接接續前一天的工作。
「每當我看到 Slack 整合，我都會開啟它，」Lawless 說。「它的功用非常多，幫助我們的流程省去許多額外步驟。」
