Day23:DevOps 工程師為何搞不定 DevOps Pipeline?(二)
昨天我們稍微聊了一下「DevOps 工程師為何搞不定 DevOps Pipeline?」,今天沿著同樣的話題繼續聊下去。
在昨天的內容中,筆者提到搞不定的原因有:
- 組織規模
- 合適的人才難尋
- 人的問題難以解決
今天我們繼續探討 DevOps Pipeline 還有哪些難題。
首先我們要先定義一下,這個 DevOps Pipeline 包含哪些內容(Stage / Job)?就讓我們詢問 Google 大神,看看搜尋「DevOps Pipeline」可以得到哪些答案?
(筆者在 Google 圖片搜尋「devops pipeline」時,最前面會顯示上圖中的這些內容。)
我們從中挑選幾個來比較一下。
Commit->Build->Unit Tests->Merge to Trunk->Integration Tests->Staging->Regression Tests->DeployPlan->Code->Build->Test->Release->Deploy->Operate->MonitorPush Code->Azure Repos->Build->Release->Deploy->Testing / Acceptance / ProductionPlan->Code->Integarte->Test->Release->Deploy->OperateVersion Control->Build->Unit Test->Deploy to Test->Auto Test->Deploy to Production->Measure / Validate->FeedbackReady to share tests->Publish to repository->Acceptance tests->Ready to ship tests->Pre-Prod->Deploy to production
上面這些範例雖然彼此使用的詞不太一樣,以及有一些 Stage / Job 的先後順序不同或拆分的粒度不同;但如果我們試著將它們統整一下,其實可以將 Pipeline 合併成下面這幾個 Stage / Job,從程式開發、送入版控、編譯、不同層級的自動化測試、交付、不同層級的部署及最後的維運。
Code -> Build -> Test -> Release -> Deploy -> Test -> Deploy -> Production -> (Test) -> Operate
你覺得在這一串 Pipeline 中,暗藏了多少玄機?讓我們隨意的列舉看看⋯⋯
- Code、Build:程式語言先天後天的差異、不同的編譯方式、不同的相依性管理⋯⋯
- Test:不同層級的自動化測試、測試案例的管理、自動化測試的效率及速度、程式碼掃描、Security 的掃描與滲透測試⋯⋯
- Release:Artifacts 的生命週期管理、Release 文件管理、版本號管理、相依性管理⋯⋯
- Deploy:如何建立不同的環境、如何部署至不同的環境、不同的部署策略、部署方式、部署相關的權限管理、目標環境的相依性管理、自動化部署該執行哪些動作、如何 rollback⋯⋯
- Production、Operate:資安、監控、日誌、分析、SLA、災難還原、Test in Production⋯⋯
根據上面的例子,我們可以發現每一個 Stage 都有多項值得探討的議題需要處理,有的只要善用工具就能解決,有的需要跨團隊的建立共識與原則,但也有些議題較為複雜,在議題與議題之間會相互交疊、彼此影響,讓人無法簡單的各別擊破,必須更全面性的處理它們。
(越是認識 DevOps,筆者就越覺得 DevOps 內含的議題就如同上圖,它們並非單純是點與點之間的連結,而是每一個點都還有著自己的影響範圍,導致議題之間是會彼此交疊互相影響的。)
你說這條 DevOps Pipeline 真的是一位 DevOps 工程師能夠搞定的東西嗎?
不,也許我們應該說,我們真的只是在處理一條 DevOps Pipeline 嘛? 或者,我們真的只需要處理那條 DevOps Pipeline 嗎?
還記得筆者在 Day12 聊到的內容嗎?我們那時就已經聊過了——DevOps 不只是 CI/CD。
同樣是連續假期的日子,就讓我繼續偷懶一下,聊少一點嘍~ DevOps 輕鬆聊,我們明天見~