DevOps 8 字環的誤區：左環問題
本文整理 2018/12/07 我寫的一篇論述：DevOps 8 字環的誤區。
左環的問題
這張 DevOps 很有名的 8 字圖，我不只一次說過這張圖有問題 (因為出處是某些大神)，但很少人可以瞭解有問題在哪。
先講結論，我認為的問題在於：
Build 的下一個不是 Test
當然我知道這只是圖示，為了方便表示，可能因此 省略 很多細節。但是就是這個省略，透過網路的傳播，以後都真的省略了。
測試前的準備工作
在開始說明圖中的誤區之前，整理測試前要知道的事情。
在我的觀念裡，Deploy (or Installation) 是測試人員的第一個 必備硬技能 (軟技能則是：溝通技巧與問題分析能力)。不管是 backend, frontend, desktop application。不包含 Deploy Strategy (Blue/Green, Canary, A/B …) ，這段通常會跟 Dev / Ops 合作，或者整個團隊一起來。
測試或者 QA 該具備的軟硬技能，請參閱：How to be an SQA?
以現代服務導向的架構來看，至少會有 Web/App + Backend 三大部分，所以測試前要準備些什麼？我覺得要完成以下必要的條件：
- 確認準備測試的
版本編號(SemVer) - 確認可以 Build 出 Artifact 位置
- Build 的依賴有沒有需要調整或者刪減
- Artifact 存放的位置與資訊
- App Build 的方式
- 確認環境是否可以重新 Provisioning
- 有沒有新增角色、如何部署
- 確認 Config 的必要依賴資源、資訊是否完整
- 確認相關服務的 endpoint
- Funciton 有沒有新增引數、第三方依賴
- 引數的預設值與邊界值
這些資訊，通常是由 PM / Tech Lead / QA Manager 一起確認，如果有使用第三方資源，甚至要先去採購。最後這些資訊都要被統籌管理，屬於企業資產的一部分。
認知差異
關於測試，後來發現一個認知上的差異在於：
- 大部分 (> 95%) 的人認為：測試只有測
商業功能，不包含系統 (或稱非功能) - 我認為的測試：不只是測試功能，還包含非功能、系統、效能
- 測試種類以及目的會隨產品特性以及開發方法有關係，所以必須要搭配測試執行策略 做選擇以及調整
測試種類、策略介紹參閱： ofollow,noindex" target="_blank">Stages in Software Testing
回到八字環，我認為的誤區、有問題的第一個點是左環 Dev 裡 Build -> Test 的部分，缺少的補充如下：
- Deploy 之前要有Artifact、Provisioning、Config
- Build 之後不是 Test，而是 Deploy
- 沒有 Deploy 的測試，請問是誰 Deploy？
- 這個 Deploy 的人知道測試的目的與策略？
- 能獨立 Deploy，就知道 Artifact、Config，然後才有 Testable 可言，才有測試策略
換言之，測試者無法自行部署的應用程式、自行配置 Config，等於無法瞭解應用程式在系統的狀況，狀況包含系統架構、版本資訊、資料庫 DDL、Init Data、第三方倚賴，無法自行建立測試資料，這種測試，等於沒有測，或者沒有意義。產品上線後，隨著時間越久，這種問題會越來越嚴重，最後 QA 會越來越沒價值，然後上面就會說：請工讀生就好。
這張 8 字迴圈，表達的大方向沒有錯，但是卻因此弱化了測試該要有的資訊，間接誤導很多人。
誤區與問題
因為觀察到普遍的團隊 (> 90%) 認為，測試只有商業功能需要測試與驗證 (Functional Verification Test)，而非功能性是維運團隊、或者是開發人員的任務。所以在開發過程，很多團隊 (>80%) 的做法是：
測試環境的部屬都是透過 Pipeline (e.g., Jenkins, Gitlab CI) 部署
而 Jenkins 的 Job 是由開發 or 維運團隊負責，換言之測試者完全沒這方面的能力或者主控權。或者部署 DB Schema 許可權都在 Dev 手上，最後問題就是 Dev 聲音很大，QA 沒聲音。測試環境的 Baseline 紊亂，或者沒有 Baseline。Baseline 就可以以從無到有建置的標準方法。
恩，這件事對我來說是不可思議的，而我這樣的想法，對很多人來講是不可思議的。所以導致大部分測試工作 在一般人心裡會覺得取代性很高、沒有價值。
系統性測試
很多問題，不管是商業需求的問題、還是系統架構面的問題，都是可以再上線前探索的。聽過很多人會說，很多問題要上線後才能知道，或者模擬。實際的問題在於規劃不清楚，上線後錯誤的資料造成 連鎖效應 (SRE CH22) 導致。這段只要 Unit Test、整合測試、系統測試有執行，是有辦法找的。而線上問題，要可以搬回線下驗證，特別是 Priority 不高，但是 Severity 很高的問題，這種情境有沒有？有，很多，特別是產品上線 兩年後 會爆多，簡單講：重要不急的問題。
測試是產品開發出來後，第一個完整的使用者，特別是這年代所謂的功能是要：Web/APP + Backend 才算功能，IoT 還要加 Devices 共三方。
更多系統測試參閱： 輕鬆聊：系統測試 (SVT) 的三兩事
專業之死
另外這年代強調團隊，弱化個別職能，很多人會說：這就找 Dev 來一起弄就好，QA 幹嘛搞這個。問題就來了，沒 Sense 的 Dev，不會把架構弄好，不會設計 Config or 做 Artifact ，做出緊耦合、強依賴的 Pipeline，最後只會讓整個服務卡死在 Dev 手上。而 QA 開的 Defect 不是隻有商業功能的問題，還包含 Config 設計不良、架構沒彈性、效能不佳 … 等。Ops 呢？根本不用插手，前面就爛了。
小節
莫名其妙就寫了一大堆，重點以下：
- Build 之後不是 Test，而是 Provsioning -> Deploy
- 測試種類很多，他們有不同的策略與考量
- 線上重要不急的問題，要可以現下驗證以及改善
- 環境建置 是一個工程團隊該有的基本素養
- 建置環境的前提是架構要清楚
- QA 開的 Defect 不只有功能的問題，還包含 Config 設計不良、架構沒彈性、效能不佳 … 等。
在地表上，除了太空船，沒有不能測的。
因為看過太多錯誤的認知與觀念，因為某某大神照本宣科，大肆宣揚此圖，加上沒有深度的思考，錯誤的觀念在網路上廣為流傳，一錯再錯。
所以這張圖不只左環有問題，右環也有問題：Deploy 前後也不是那樣的。