CICD
###### tags: `CICD`
===
## 章節目錄
[TOC]

## 一、為甚麼要workflow

CICD是一種方式:

- 標準化
共同的開發習慣
- 自動化
標準化之後可以自動化
- 透明化
資訊不對等可能導致誤判沒辦法協作

### 為甚麼要Pipeline? 誰要負責規劃/建置/維護?

## 二、Devops LifeCycle

大型企業的維運跟開發會常常吵架，有時候說是code問題，有時候說是server問題，常常吵得不可開交。

### 書的推薦
[鳳凰專案：看IT部門如何讓公司從谷底翻身的傳奇故事](https://www.books.com.tw/products/0010765203)

有時候火燒起來DEV丟過去就牆擋起來
.
但希望牆中間可以有一些開口，且有不只開發跟維運有問題，每個出口都有牆擋著

### 到底甚麼是DevOps?
有人說是開發跟維運之間要打通，但有人說是從客戶端到全部落時都要打通，各自定義都不同。

實際上應該會長得這樣

### 敏捷開發會長這樣

所以為甚麼要打破中間那道牆?
因為要順暢和高品質地交付有用的價值。

**消除浪費，使價值交付最大化**
所以有良好的workflow跟pipeline很重要，因為這樣可以消除浪費，讓價值交付最大化

### GitLab LifeCycle

#### 名詞定義不是個重點
不同的公司會有不同的做法，不用拘泥於workflow pipeline lifeCycle的名詞爭奪，也很難作詳細的定義跟切割，重點要找到一個好的符合公司的工作流程出來。

#### 會影響Devop LifeCycle方式的是
- 人/公司文化
- 流程
- 技術/工具

## 三、CI/CD

### 你想像中的CICD
CICD不就是要自動建立pipeline部屬嗎?推上去之後自動build掃描跟部屬，部屬成功最後寄email告訴我不屬成功不是嗎?

### Continuous Integration
所以甚麼是CI? 中文就是持續整合

常常自己的電腦都沒有問題，到別的環境之後就都會出問題，所以我們需要CI來作。

#### 為甚麼是CI?
CI是一個最低限度的守門員

但需要多頻繁的驗證呢?
**盡量每次異動，都要驗證**

所以沒有自動化測試，作驗證
不要說你是在做CI。你pipeline上面沒有驗證，就只是工作自動化而已。

#### CI遵守的七大原則

常常沒有整合就容易發生未知的問題，若發生問題可能就有更大的問題要修復，然後你旁邊的同事繼續產生code產生更多bug。

所以常常把小小的異動做驗證就可以提早的發現問題，提早審核跟提早修改，對code跟開發者都是好事情

若沒有常常推發現錯誤，十幾個人的code一起送上去就一起炸掉，這樣就會很慘修很久

#### 小結
- 頻繁整合程式碼
- 建立團隊開發協作的節奏
有些公司是不管寫得怎麼樣，下班前都要commit
- 及早取得回饋、發現錯誤
拆得很細碎來做commit
- 建置流程的標準化跟簡化
- 降低錯誤成本減少浪費

### Continuous Delivery(持續交付)
目前不僅是部屬自己的程式到各種環境，也有可能一起要做環境變數的交付。

- 現在交付有非常多的人跟版本，交付都有不同的樣貌跟形式

- 交付寬鬆的定義是

#### 交付涉及的有
- 環境管理
- 組態設定
- 先通過持續整合
- 先通過自動化測試
- Artifact Management (存取跟管理)
- pipeline
- 還有Deploy/Infra/Data/VCS/Dependency


#### 持續交付的原則

#### 持續小範圍的整合跟交付(環境變數、code)


每次的CICD都是一個守護最低限度的品質。
並及早發現及早修復問題。

你說infra怎麼測試?
現在有infra service as code

#### CICD不是自動化
但CICD真的不是自動化，還有測試，自動化的不應該只有部屬而已，難怪大家都只會想到自動化。

持續整合跟持續交付最重要的還是自動化測試驗證。

#### 甚麼是自動化

自動化要跟CICD切開來，你今天要做的是人工驗證，還是只是想省時間而已，要明確確定你的目的來做。


CICD不是自動化，但CICD可能裡面有部分自動化的可能。

所以不要為了自動化而自動化。

## 四、Git、GitHub、GitLab分不清楚
- 現在CICD pipeline起點都會是我們的版本控制系統，Git大概是大多數我們觸發CICD Pipeline的起始。

- GitHub跟GitLab各有優劣，就看自己公司想要怎樣的版本控制系統跟Pipeline，此外也有Gitea這樣的廠商提供服務，都端看自己的需求而定。

## 五、GitLab: The One DevOps Platform(一站式Devop平台)

- 大概是從Project Management到第十五版開始有DevOps現在還有DevSecOps，功能也越來越多。

為何用GitLab

- 免費
- 容易維運(架設、升級、使用跟管理)
- 吻合團隊工作流程
- 自行架設方便
- 直接整合的CI/CD工具
- CI/CD工具好用易用，且滿足多數需求

### DevOps四種演進

### 一站式的好處
- 一站式的好處，不同部門跟團隊都在同一個平台做事，讓資訊透明化讓大家可以做交流，打破交流的牆。

- 從一個平台獲得關於專案開發到維運的所有資訊
- Merge Request強制成為資訊彙整點跟檢核點，盡可能的自動化其中的流程跟檢核
因為MR的時候會跑很多掃描，會強制開發者在那邊做修正。讓驗證檢查的事實會發生。

## 六、結論
有一個好的pipeline可以提升團隊的生產力跟效率，有效的朝向同一個目標前進


CICD就是守護者 真的不等於自動化

CI/CD原則
- 建立可重複且可靠的流程
- 盡可能的自動化
- 用版本控制管理並保護依竊
- 越棘手的是，越要盡早且頻繁處理
- 重視品質
- 交付價值式每位成員的責任
- 持續改善(最重要的)
CICD需要持續改版，不會一次就完成有一個完好的pipeline，漫漫長路持續改善是躲不掉的。

### 到底誰要搞定流程?
全都是相依關係，有辦法只靠SRE搞定嗎?
不行，因為涉及整個團體的人、流程、技術

選擇工具只是剛開始，選擇某個工具是技術長的職責，工具選擇的策略也很重要。根據團隊來做調整。

先搞清楚code 部屬環境 怎樣部屬 怎樣管理環境 最後再來討論怎樣搞CICD，程式語言生態系先弄懂再來搞懂後面的東西。

先搞懂怎樣手動跑，再來做自動化，自己跑可以也跑到其他環境做可能就可以共用了，慢慢放進去pipeline中

### 前端與CICD
先搞懂大部分的環境，比較不會讓前端處理CICD，但前端也會進去gitlab也比較不會去直接處理到。
但可能UI test，可能用selenium去做測試。這樣也可以比較廣泛的前端測試，有公司也丟給QA Team，看公司。