# DevOps
###### tags: `RD1`

:::spoiler 目錄
[TOC]
:::

## 什麼是DevOps?

### DevOps到底是怎麼來的呢？

DevOps運動承襲自敏捷系統管理（Agile System Administration）運動以及企業系統管理（Enterprise System Management，ESM）運動。

在那個年代有一位比利時籍IT顧問Patrick Debois，他與政府部門合作，共同進行資料中心遷移的計畫，而他則負責相關測試工作。Patrick Debois必須時常在開發團隊以及維運團隊間變換角色。前一天他正習慣於敏捷開發的步調，第二天卻必須上陣救火，確保系統能正常維運。經歷此項計畫後，Patrick Debois了解到，開發團隊與維運團隊不僅中間像隔了座山，運作方面還處處衝突。

在2008年時，Puppet實驗室共同創辦人Andrew Clay Shafer跟Patrick在多倫多的Agile大會中相遇，他們兩個人都認為，必須思考出一個方式，搭起開發團隊與維運團隊之間的橋樑。

<img src="https://i.imgur.com/hqzf9ah.jpg" height="400">
<img src="https://i.imgur.com/zU7MXEh.png" height="400">

<br>2009年6月23日，在加州聖荷西O'Reilly Velocity大會上，兩個Flickr的員工，資深技術維護員John Allspaw以及領導工程師Paul Hammond，在會議中報告了一個主題：「10+ Deploys per Day：Dev and Ops Cooperation at Flickr」震驚了許多在場的開發者，因為一天內部署超過10次是何等艱難的任務。此演講很快速地受到社群的認同，因為他們證明了開發團隊與維運團隊彼此是可以順利合作。John Allspaw跟Paul Hammond認為打造新一代軟體的方法應該是讓開發團隊及維運團隊兩個都變得透明，並將兩者互相整合在一起。

<img src="https://i.imgur.com/LeXgseB.jpg" height="300">
<img src="https://i.imgur.com/z44FNKm.png" height="300">

<br>此時，隔著大西洋觀看直播的Patrick Debois受到很大的激勵，他在推特上表示，如果能親臨現場該有多好，而很快地就有人回覆他的推特，並表示何不自己在比利時舉辦一個活動，這樣大家就可以參加了。雖然是推特好友的一句玩笑話，卻無心插柳柳成蔭，讓Patrick Debois決定開始籌組自己的活動。

也就是現在全球知名的一個活動「[DevOpsDays](https://devopsdays.org/)」。

### 一張DevOps的圖片
<center><a href="https://medium.com/bryanyang0528/devops-%E6%AA%A2%E8%A6%96%E4%BD%A0%E7%9A%84-devops-%E6%8C%87%E6%95%B8-d0b380c3298b">[DevOps] 檢視你的 DevOps 指數</a></center>

<br>由這張圖片能夠看得出來，DevOps是由兩樣東西組合而成，也就是Dev(Development)以及Ops(Opreation)，代表現在軟體開發的一種模式。

一般而言，開發的過程中會遇到許多階段，包含寫code，包版，測試，上版，到部署等等階段。而產品開發並不是做完一個版本就完成了。而是完成一個版本後，理想的情況是企劃或是行銷會根據市場變化或是使用者需求，要求開發新功能，而壞的情況則是發現測試時沒測到的bug，需要立即Debug，這就是改版，而這個改版需要被非常快速地執行，尤其是現今行動網路時代，市場變化大且 Winner takes all，特別非常適合新創公司，需要變化快速的對應改版，因此此方法就被提出來了。

過去開發中的階段，如圖所示，可能有開發人員或是營運人員，在各個階段負責執行，但也造成了許多人為的動作，不僅耗時有時也會造成溝通的問題，阻礙產品的上線時程。

DevOps想法跟大部分的Agile方法類似：提高透明度，並整合兩者。
可想而知，團隊間的資訊越透明，整合度越高，發生衝突的機率會越小，而 DevOps 最初的目標，正是要解決 Dev & Ops 之間的衝突！
### DevOps的定義

維基百科上是這麼說的
> 是一種重視「軟體開發人員（Dev）」和「IT運維技術人員（Ops）」之間溝通合作的文化、運動或慣例。透過自動化「軟體交付」和「架構變更」的流程，來使得構建、測試、發布軟體能夠更加地快捷、頻繁和可靠。

又有一本書是這麼定義的
> DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.

那我知道大家不想讀英文所以直接幫大家google翻譯
> DevOps是一組旨在減少從提交系統更改到將更改投入正常生產之間的時間，同時又確保高質量的實踐方法。

簡單來說就是「盡量減少提出改變到改變上線之間的時間，同時要維持好程式的品質」。

## DevOps想要達成什麼目標？

- 時間：在「commit change」到「上線營運生效」兩者之間的時間差，要盡量縮短到某個設定的水平之內。

- 品質：不能只求上線生效，還要對品質把關，維持在某個設定的水平之上。

## DevOps的核心

總共有五點，俗稱「CALMS」。

### Culture
DevOps 並不是一種技能，不是叫開發去學如何管機器，也不是叫維運去寫程式。
DevOps 的 Dev + Ops 是指「開發多去想維運面，維運多去想開發面」。
舉例來說，開發寫程式時，把設定檔設計的非常適合維運人員管理；或是開發想導入一些套件管理工具，維運可以支持並配合上線。

### Automation
自動化將會是個很重要的要領，它是需求的潤滑劑，需求丟給開發人員開發完後，有了自動化測試，很快就會滑到準備上線；有了自動化佈暑，就跟阿基師一樣滑不小心就滑到上線了。

另外，它也是團隊合作的潤滑劑。

比方說，原本的障礙：開發人員要上線時，丟了一包程式，然後維運人員丟上去沒多久，客戶就打來說壞了。維運人員查了半天才發現原來是新程式有用到第三方 library 沒包進去，接著又繼續搞半天，只為了把 library 安裝至正式上線的機器上，想當然而，維運人員就會說話了。不過開發人員這時出來講話了：程式裡有文件啊！

大多數的狀況下，管理層面的人會出面提議兩邊坐下來討論，接著就會出現 SOP 。比方說，開發上線前要測試，測試完要寫測試報告，然後填寫上線文件與表單送交維運，等待維運上線。這一類的 SOP 通常每次的內容都差不多，久了就會有人開始不想寫。然後，換開發人員靠邀了。

其實，每次上線的流程大同小異，有自動化能取代 SOP 的話，這一類的靠邀就能避免掉很多了。

### Lean
精實就會提到精實軟體開發的七大原則，但在這邊就提一下不詳細深入的講解，這邊提供一個網站有比較詳細的講解精實軟題開發的部分。
<a href="https://ithelp.ithome.com.tw/articles/10219431">Lean 精實開發</a>

- 消除浪費 (eliminate waste)
- 增強學習 (amplify learning)
- 盡量延遲決策 (decide as late as possible)
- 盡快交付 (deliver as faster as possible)
- 授權團隊 (empower the team)
- 嵌入完整性 (build integrity in)
- 著眼整體 (see the whole)

### Measurement
DevOps 也具備著 Agile 的精神，所以不怕改變。但改變總是要有憑有據，有了測量，可以提示團隊如何做更正確的改善。通常測量的目標會是維運時期的數據，但其實從需求到上線整個流程的過程，都有可以記錄的地方，比方說某個需求在開發過程中所出現的 bug 率特別高、或是 bug 被重開的次數等，都有助於團隊思考改善的方向。

### Sharing
DevOps 是一種文化，而分享是一個創造 DevOps 文化的最好方法。分享的內容可以有很多，如文章、經驗、工具等，甚至上述的測量出來的數據也能分享給團隊所有人，讓開發人員與測試人員，甚至是業務人員都能根據數據做出最好的決策。因此，分享也是增加團隊透明度的好方法。

## DevOps 的一些實現方法
<center><a href="https://aws.amazon.com/tw/devops/continuous-integration/">https://aws.amazon.com/tw/devops/continuous-integration/</a></center>

### Continuous Integration(持續整合)
持續整合是一項 DevOps 軟體開發實務，指的是開發人員在執行自動化建置與測試之後，定期將他們的程式碼變更合併到中央儲存庫。

持續整合的主要目標是更快發現和解決錯誤、改善軟體品質，還有減少驗證和發行新軟體更新所需的時間。

### Continuous Delivery(持續交付)
持續交付是一項軟體開發實務，這項實務會自動準備程式碼變更以發行到生產環境，它透過在建置階段之後將所有程式碼部署到測試環境和/或生產環境，結合持續整合來進一步延伸。

持續交付讓開發人員不只是自動化單元測試之類的測試，所以他們將應用程式更新部署到客戶之前可以從多方面來驗證更新。這些測試可能包含 UI 測試、負載測試、整合測試、API 可靠性測試等。這可協助開發人員更徹底地驗證更新並提前發現問題。

### Continuous Deploy(持續部署)
使用持續交付，每個程式碼變更都會經過建置、測試，然後推送到非生產環境或模擬環境。在生產部署之前有多個並行的測試階段。持續交付與持續部署的差異在於從更新到生產的手動核准。使用持續部署，無須明確的核准即可自動進行生產。

## DevOps有哪些工具呢？

想知道有哪些工具的話，可以看看下圖。
<center><a href="https://www.edureka.co/blog/devops-tutorial">https://www.edureka.co/blog/devops-tutorial</a></center>

<br>只要提到DevOps，其中最重要的工具就是Jenkins。Jenkins是一個CI/CD軟體工具，負責協助整合從開發到測試，包版到包版的的各項流程及動作。它不僅是免費的，且社群龐大，不斷更新又有許多的Plugin，是現在最主流的CI/CD工具。

這邊提供一個網路上的教學是利用Docker去建立Jenkins。
[用 Docker 安裝 CI/CD 工具 Jenkins](https://medium.com/@zoejoyuliao/%E7%94%A8-docker-%E5%AE%89%E8%A3%9D-ci-%E5%B7%A5%E5%85%B7-jenkins-347ffe630e40)

## 參考資料
[DevOps-維基百科](https://zh.wikipedia.org/wiki/DevOps)
[什麼是DevOps?](https://ithelp.ithome.com.tw/articles/10184557)
[為什麼會出現DevOps](https://www.ithome.com.tw/news/96861)
[一句話囊括DevOps](https://william-yeh.net/post/2016/01/devops-goals-in-a-nutshell/)
[什麼是DevOps?](https://aws.amazon.com/tw/devops/what-is-devops/)
[Lean 精實開發](https://ithelp.ithome.com.tw/articles/10219431)
[DevOps 簡介與概念](https://medium.com/@kuanweilin/devops-%E7%B0%A1%E4%BB%8B%E8%88%87%E6%A6%82%E5%BF%B5-6e7fda3eaa6d)
[用 Docker 安裝 CI/CD 工具 Jenkins](https://medium.com/@zoejoyuliao/%E7%94%A8-docker-%E5%AE%89%E8%A3%9D-ci-%E5%B7%A5%E5%85%B7-jenkins-347ffe630e40)
[\[DevOps\]檢視你的 DevOps 指數](https://medium.com/bryanyang0528/devops-%E6%AA%A2%E8%A6%96%E4%BD%A0%E7%9A%84-devops-%E6%8C%87%E6%95%B8-d0b380c3298b)