GitHub DevOps 流程参考实现

在这篇文章，我们来讨论 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 有更全面的了解。