# SRE 讀書會 Round2 #4 共筆 CH.3

## 第三章 持續整合

## 內容大綱

### 實作持續整合

* 準備工作
* 基本的持續整合系統

### 持續整合的前提條件

* 頻繁簽入
* 建立全面的自動化測試套件
* 保持較短的建制合測試環境
* 管理開發工作區

### 使用持續整合式的軟體
* 基本操作
* 鈴聲和口哨

### 必不可少的實踐

* 建置失敗之後不要簽入新的程式碼
* 調交前先在本地執行全部的提交測試，或是持續整合伺服器完成此事
*

## 第一段討論

### 第一組
人員: 義格, 鎧陽, 建銘, 小明
實作持續整合 + 持續整合的前提條件
義格: 本章和軟體開發很有關係, 尤其是自動化建置. 目前遇到的困難, 有一部份程式只能用 IDE build (ex: flash)
前提條件: 一定要頻繁簽入, 代表 RDs 溝通頻繁
小明: PIXNET每天 commit 的次數非常多, 為了能減少衝突
建銘: 和人數有差嗎?
義格: 版控在個人上, 是很方便, 可以做紀錄
目前在公司上只能做到功能是否正常
鎧陽: 如何管理開發工作區?
義格: 開發者的環境和 production 環境要一樣. 我們公司都是用 windows, 所以利用 VM 來管理開發工作區
建銘: 開發工作區可以用 docker

echo:

正瑋: 對 ansible 來說, 最後要能減少對 ansible 的依賴, 讓裡面每個 script 都能獨立執行, 當未來 ansible server 出問題時, 還能手動 deploy
jon: 用 docker 能快整 rollback

什麼是 CI 認為的必要條件?
unit check, 測試很重要
version control
commit 頻繁

PXE + Ansible...

### 第二組
軟體選擇
1. gitlab-ci
2. bitbucket pipeline
3. jenkins

gitlab-ci
預設會在 pipeline 裡執行 3 個階段： build, test, deploy
push 後就會自動跑測試，只需新增.gitlab-ci.yaml
現在還有autodevops功能 基本上就是玩k8s
也可以手動啦

請QA給一個基本的測試環境
>可能是本地端或雲端
commit前先確定基本測試會過

本地端環境可能不同步
定時同步環境以確定pretest能先抓到大部分問題
如果下班前一直不過就rollback

下班前一小時盡量不commit 以免加班

測試跑太久就FAIL 以免拖到整個流程

抓到錯誤要能注意到 甚至可以連接到實體設備

類似戰情大螢幕或是LED燈 不要讓他默默的過去

組織有錯誤能提早被抓到其實是好事

但客戶看得到可能會不爽

組織內部也一樣 要對事但是不對人
能面對錯誤也是流程的一部分

Unittest 由開發人員自己寫，functional/component test 由 QA 來寫

### 第三組

挑選工具時的原則：
1. 能否延續既有的應用情境
2. 功能全面性，plugins 數量、生態系發展、社群發展狀況
3. 是否能夠完善的權限控管
4. 學習曲線
5. 費用
6. 是否容易與第三方整合
7. 是否有完整的解決方案
8. 是否容易結合地端、雲端多種環境

CI 的原則（前提條件）基本上大家都大致相同。

題外話，當年的 Jenkins 使用起來有一點囉唆，雖然什麼都做得到，但相對的也需要設定很多東西。
題外話，如何取得團隊共識，例如挑選工具這件事。這其實是政治問題，有時候是直接聽 Leader，他就是選了。當然有些會有持續對話，勸說團隊成員接受。

### 第四組
使用的工具：主流還是 Jenkins
gitlab-ci 、bitbucket
工具算其次，重點在 pipeline 、可抽象化、可程式化

案例：
* 使用SVN 、一直有 commit 進來。只好直線改下去，沒得 revert /stop
* 訂規範在一定 %數一定要補 coverage
* 正視 CI 的 faild

### 第一階段報告
書中提到自動化建置需要使用 cli 才能執行，但不幸敝公司有使用 flash 是沒有辦法這樣 build 的，變成無法吻合 CI 準則，flash 這一段就必須要人工手動執行。

管理開發工作區，這很重要，因為可以快速恢復環境。甚至是否有辦法讓開發與 prod 是盡量一致的。
因此可以將開發工作區封裝，有助於環境還原。
環境管理也會影響著是否能達到「CI 可隨時還原（部署任何版本）至任何時間點」
追求 Local-dev、TEST-env、Prod-env 環境一致性，流程從下往上逐步完成。
流程上，除了依賴工具，但也要俱備失去工具時的流程。

環境的管理、控制，除了 SRE 與 Ops 之外，Dev 也需要有介入（溝通、取得共識）的空間，例如是否 Dev 負責將整包的 dockerfile 完成，確保從開發開始的環境就是一致，甚至後面可以直上 K8S。

在 build 時，如果有相依性、第三方套件的需要，各位怎麼處理的？
- 在自己的 local、公司內 建立副本 server
- infra as code 所有都用 code 記錄
- 有專人管理，第三方套件都必須通過內部認可才能使用，並且內部打包一份

CI 一定要有的東西：
1. VCS
2. 測試 -> 因為是保護，也是品質保證，才不會部署之後又一直 rollback。產品出去才會有信心。
甚至要求一定的測試覆蓋率，或 daily build。

### 第二階段報告

Jenkins

CI 最重要的原則：
- 最好都是綠燈
- 自己要管好自己的 build、燈，紅燈要趕快修，設定一個修理期限，不然就 rollback
- 紅燈就停，直到修好為止，不可進其他新的，避免把別人的也搞爛了。
- 週五下班前不可以 commit。

在自己的BOX 或者另外給一台機器
建立基本測試環境
測試過了就自動commit

跨時區工作會因為紅燈互卡

只有一條branch (Trunk Based Development)
多條 branch 違反CI/CD 原則
（這點可以討論一下，CI / CD 原則是否隨著時代有所改變了？）
（不同規模的公司、軟體架構，是否都是用同樣的 CI/CD 原則）
>單線多TAG管理？

Q: 在有時間壓力之下，6000 多個 unit test 只有一個 failed，你會怎麼處理？
- 看問題嚴重性，是否這個壞了一定不能上線。
- 這是政治與權責問題，需要協商
- 還是看團隊的原則，例如：紅燈過了是否一定不給過