GitLab 和 Mattermost
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10217953）
昨天已經簡單介紹過 GitLab Workflow，今天就讓我們進入在談到第 1 步驟 Idea 時曾提及的工具——Mattermost。
【新增補充】GitLab 原廠已經捨棄 GitLab Workflow，改為倡議 DevOps Lifecycle，至於 GitLab Workflow 則被原廠拿去當作 VS Code extension 的名稱。 GitLab 原廠不止捨棄原本推崇的 GitLab Workflow，甚至將當年介紹何為 GitLab Workflow 的 文章徹底刪除（即是本文「參考資料」中的連結 https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/），只能說官方真是做得很絕。 因此本文的關於 GitLab Workflow 的內容基本上都是過期了，但雖說是過期，也只是對於 GitLab 原廠而言是過期的，筆者個人的想法是，它依然是一個值得我們參考的範本，如果你對於該如何規劃自己團隊的 Workflow 毫無頭緒時，它依然是具備一定程度的參考價值。
安裝 Mattermost
如果你當初安裝 GitLab 採用的是艦長推薦的以 Omnibus GitLab 的方式安裝，那麼安裝 Mattermost 對你而言將會是一件非常簡單的事，你唯一要擔心的就是 Server 如果 Mattermost 也和 GitLab 安裝在同一台 Server，那 Server 的資源是否足以支撐服務的正常運作。
能夠輕易的安裝 Mattermost，都要歸功於 Omnibus GitLab 專案。當初 GitLab 選擇 Mattermost 作為合作夥伴之後，便將 Mattermost 的安裝與組態配置納入 Omnibus 專案內。因此只要你當初是透過 Omnibus GitLab 安裝 GitLab Server，現在只要修改 GitLab Configuration，並再次執行 gitlab-ctl reconfigure 就能輕易的架設 Mattermost。
# Mattermost 安裝步驟
## 修改 /etc/gitlab/gitlab.rb 的以下兩個設定值
mattermost_external_url 'http://你想要將mattermost架設在哪個domain'
mattermost['enable'] = true
## 接著再執行指令
sudo gitlab-ctl reconfigure
使用 Mattermost
當首次開啟 GitLab Mattermost 網站時，會出現類似下圖的畫面，引導使用者建立帳號。透過 Omnibus GitLab 架設 Mattermost，在 Mattermost 安裝完畢的同時，也已經與 GitLab Server 串接了認證機制，可以透過 Single Sign-On 的方式直接登入 Mattermost。
（只要 User 已經擁有 GitLab 帳號，即可直接使用 GitLab Mattermost，無需重複註冊。）
（只要按下 Authorize 授權即可登入 Mattermost。如果你使用的是 GitLab 的 Admin User，在登入 Mattermost 時，也能一併取得 Mattermost 的 Admin 權限。）
在使用 Slack 時，為了區分團隊或部門，有時我們會建立不同的 Workspace，徹底切分工作環境。而在 Mattermost 同樣的概念，則是稱為建立不同的 Team。
（Admin 首次登入時，記得先為團隊成員建立第一個 Team 吧！）
Team 設定完畢之後，就如 Slack 一樣，Mattermost 也可以依據需要在其中建立多個 Channel。
（Mattermost 的介面與操作方式皆與 Slack 非常相似。）
Mattermost 也和 Slack 一樣，能夠與 GitLab 有許多整合，像是針對 Project 的異動主動送出通知至 Channel；也可以串接 ChatBot 實現 ChatOps。
（在 GitLab Project 的 Settings > Integrations 即可找到 GitLab 與 Mattermost 的整合設定。）
小結
透過 Omnibus GitLab 的幫助，架設 Mattermost 並讓它與 GitLab 建立 Single Sign-On 認證機制已十分容易。如果你和文章中的假想團隊一樣，也打算導入整套的 GitLab Workflow，那麼直接以 Mattermost 取代 Slack 是不成問題的。因為 Mattermost 使用起來與 Slack 非常類似，對於已習慣使用 Slack 的工程師而言，幾乎可以無痛接軌的轉換到 Mattermost。最終，最大的難處恐怕還是 Server 的資源是否充足，以及因為是自行架設 Mattermost，於是維運人員又要煩惱 Mattermost 會佔用多少系統資源、歷史訊息該保存多久、會佔用硬碟空間、該如何備份與還原⋯⋯。
今天只是快速地認識了 Mattermost，關於使用 GitLab 該如何將 Mattermost 與 GitLab CI 及 ChatBot 整合，就讓我們就留待介紹 CI/CD 時，再來說明了。我們明天見～