在這篇文章，我們來討論 GitHub 與 DevOps 之間的關係，我們將從各種角度來討論，GitHub 如何實現 DevOps 流程。其實在許多 GitHub 既有功能中，你可以發現一些 DevOps 的蛛絲馬跡。

一般來說，多數的 DevOps 流程應該是從專案管理(Plan & Track) > 開發(Develop) > 建置與測試(Build & Test) > 維運(Operate) > 監控與反饋(Monitor & Learn) 的流程進行，達到持續整合與持續交付之目的，如下圖所示：

但以 GitHub 的角度來看，起點不是從專案管理 (Plan & Track) 開始，而是從儲存庫 (Repo) 開始。而其他的功能是圍繞著儲存庫而生，包含 Project、Action、Milestone、Issue、Pull Request、Template...等。這樣與眾不同的 DevOps 流程具有一個優勢，即是聚焦於該儲存庫的內容與交付品質，避免在 Plan & Track 階段失去焦點，導致專案走向越走越偏。

軟體品質與安全

另一方面而言，每個外部的修改均需要以 建立 pull request 形式進行，Owner Code Review 後，確認才能 Merge 至主要分支。另外以 Security 角度來看，因為 GitHub 以 Repo 為中心，所以很早期就導入 "對 Repo 進行相依性與弱點掃描"。有些稍微了解 DevSecOps 的朋友可能會覺得這情境挺熟悉的，其實這就是 DevSecOps 提到 左移安全(Shift Left Security)，在開發階段即實施安全措施。

左移安全的目標建立最佳的安全實踐，並軟體開發生命週期中儘早找出/修復安全問題和漏洞。而並非在完成所有測試後才實施安全措施，造成大幅增加開發(修復)時間，或導致沒有安全措施下直接發布軟體。許多研究指出，左移安全可以更容易、更快、更節省成本的解決安全問題。

專案管理

而一般專案來說，依據團隊屬性不同，開發流程可能是敏捷、Scrum、CMMI 或 waterfull，但以Github 的功能面來說，卻沒有 "直接" 跑以上的開發流程。 很詭異? 別擔心，以 GitHub 現有功能來說，流程可以將從既有功能中組合出來。

Agile 概念 與 GitHub 概念圖如下，你可能會發現，除了 Issue 與 Task、Pipeline 與 Action 可以對應起來，其他部份似乎無法直接使用? 這代表使用 GitHub 就不能執行敏捷嗎?

其實不盡然，您可以直接將 GitHub 功能做搭配，即可建立出相同的 Agile 流程。舉例來說，User Story 可以由 Issue + Label(自訂) + Template 達到相同的效果。組織內無論使用哪種管理流程，皆可以以類似的方式，建立出自訂的流程。

流程像是心法，而工具即是招式，招式的組合仍可以達到心法的效果

DevOps 流程參考實現

對於團隊來說，盡可能會優先考慮使用便利且好維護的工具，以降低維護與時間成本。在 DevOps 流程中，工具的支援對於開發/維運團隊相當重要，除了是迅速正確交付的基礎外，容易維護的特性可以降低團隊成員的工作負擔。

下圖以 Azure DevOps Services 流程實踐參考，您可以看見 DevOps 流程中，所使用的各種工具。圖片來源 twitter: DevOps on Azure

下圖以 GitHub 為例，在 DevOps 流程中，所使用的各種工具。圖片來源 twitter: DevOps on Azure

你可以發現兩組 DevOps 流程參考實現中，皆有可對應的既有/第三方工具，將有效提升團隊成功導入 DevOps 機會。若再導入 DevOps 過程中，若沒有相對應的工具，則可能消耗更多人力與時間成本，而導致事倍功半。

閱讀完這邊文章，你應該對於 GitHub 內的 DevOps 流程有進階的了解。下一篇文章，我們將從 Development (開發) 相關功能開始介紹與實作，結合本篇文章的流程參考，你會對 GitHub 有更全面的了解。