怎樣的 CI/CD 才夠 Quality?

前一篇『導入 CI/CD 的第一步』提到了一些基本觀念、想法，這篇繼續整理一些關於 軟體開發過程，怎樣的 CI/CD 才算是有品質。一般介紹 Jenkins、Gitlab CI、Drone 的課程重點在於怎麼利用工具串接 CI/CD Pipeline 的 Task / Jobs，除了這些，怎麼讓 CI/CD 真正達到團隊合作，我想是非常重要的。

底下是我看 CI/CD 做得好不好的 驗證點 (Verification Point)，夠不夠 Quality 就看這些了 (好像在做認證一樣 XD)：

(主詞) 可否任意建立需要的環境？
(主詞) 可否驗證任意版本？
(主詞) 如何配置 (Configure) 整個系統？
(主詞) 可否隨意建立模擬資料？
收集回饋機制
產品開發團隊有哪些人？

為什麼 CI/CD 要有 Quality?

理由只有一個：減少溝通成本

溝通造成的成本其實很恐怖，所有人都在為一件事情努力，但卻一直在原地踏步，甚至走回頭路，更慘的是：沒有察覺這是個嚴重問題

如果為了確認一件事情，不管是 Bug、還是蒐集資訊，需要透過三個以上的團隊，才能知道，我認為就是 溝通阻力 過大，這個團隊已經開始在內耗、空轉，如果又有 穀倉效應 的問題存在，那這樣的溝通，會更加恐怖。

更恐怖的是，被問的人反過來質疑問問題的人，管理團隊只知道問題卡住很久，卻不知道問題在哪 …. 發現問題的很無奈，同時也很無助。。。

更多參閱：溝通成本、導入 CI/CD 的第一步

怎樣的 CI/CD 才夠 Quality?

底下的項目是我個人的經驗彙整之後的項目，不見得是對或錯。

不會談工具，工具好、或不好，取決於人，但是觀念對了，長久來看，不會太糟。

底下標題的 主詞 請自行分別帶入組織的角色的任意角色，可以是 Dev、QA、Ops、PM、Support、Sales、掃地的 ….

一：(主詞) 可否任意建立需要的環境？

透過 Infra as Code 建立需要的環境
知道成本？用最少成本，或者最大規格？
使用者知道自己在做啥？建立出來的架構長啥樣？
有自己的 Database, Storage, DNS, SSL, CDN

相關參見： Resource Provisioning and DevOps

二：(主詞) 可否驗證任意版本？

能否隨意地回到任意版本？包含以下

Application 的版本, 任意 branch / tag
Database Schema / Init Data 的版本
Dependency Module / Package / Library

這邊重點在於 Artifacts 的建置與管理。

相關參見：Artifacts Management、聊聊軟體交付的濫觴談產出物管理

三：(主詞) 如何配置 (Configure) 整個系統？

Config 描述了系統架構
如何自行依照需求、情境，配置需要的環境？
完整的 Configure 說明在哪？誰維護？
Config Tools: 由 Dev 開發的工具
- 我上個工作開發曾 Device (IP Camera) 的 agent 更新工具，目的就是可以隨時更新 Device 的配置
Config 本身的設計，有可讀性？

一個設計好的 Configuration，可以看出系統架構是怎麼一回事。
Configuration 沒有管理，等於系統架構沒管理。

四：(主詞) 可否為特定需求，隨意建立模擬資料？

有沒有方式可以建立測試資料？例如模擬特定客戶的情境？
模擬的資料能否完全刪除？
有沒有方式可以把 DB 重新 Reset 成乾淨的？
有沒方式可以「模擬」大量資料？
這些測試資料的說明文件在哪？
敏感性資料能否做額外處理？像是 DLP (Data Leak Prevention, 資料外洩防護)
能否取得正式環境的資料？取得的流程是什麼？

收集回饋機制

使用者測試、體驗之後，有沒有功能可以直接蒐集系統資訊，像是：
- server side 的版本資訊
- client side: Mobile Platform 資訊、APP 版本、環境變數、使用者 Session 資訊
自動回饋到 Issue Tracking System，像是 Redmine
一定要有名字、Version、時間. see: Version Control

你會怎麼回報問題？軟體開發過程中的具體做法參閱：如何有效的回報問題 (How to Report Problems Effectively)

產品開發團隊

開發團隊的哪些角色會需要這些東西？

工程單位：Tester, Dev, PM
維運單位：Release Engineer, Support
業務單位：Sales, Pre-Sales, Inside Sales, Saaaaaaales~~~

就是前面標題的主詞啦 XD

想法

以前很喜歡在 IBM Redbook 挖寶，後來發現一個完整的產品通常會有這幾種文件：

Quick Start
User’s Guide
Installation Guide
Admin Guide
Performance Guide

這五個本代表五個不同面向的角色、使用者，不同角色都能看待同一個系統。

沒有上述的條件，會怎樣？

沒有前述的條件，然後說在做 Automation XXX ，包含測試、壓測，嚴格來說，都是沒有參考價值的，因為 Baseline 是不清楚的。都只是 “暫時的” 、浪費時間、沒有意義的，相信我。。。

然後，我一直覺得這些觀念是常識。。。不然你怎麼用 Open Source 下載的工具來用？怎麼用別人寫的工具？

想玩大數據，抓了 Hadoop 來裝，你怎麼裝的？他的 Configuration 怎麼設計？你看得出這其中的差異嗎？你家的軟體怎麼讓其他人安裝的？你家的 Configuration 重構過嗎？能測嗎？還是 不要問很恐怖？、這不是問題 .. 忽略？

在 Production 發生穩定性效能意義，很常見的現象是：現象不常出現、頻率不一、重複步驟不容易找，通常跟效能有關係。這時候如果可以把 Production 資料倒回 Lab 想辦法重現問題，只要找到重現問題的方法，就有機會找到 root cause，才有機會真的解掉問題。無法部署任意版本，就很難重現 Production 的問題，只能在 Production Debug ……….. 你在跟我開玩笑嗎？