DevOps 自動化工具優勢與實踐案例解析

– 11 分鐘閱讀

在軟體開發生命週期中，手動流程的低效率和高錯誤率一直是困擾開發團隊的難題。自動化工具的出現，特別是在 DevOps 理念的推動下，為解決這些問題提供了有效方案。自動化工具不僅提升了效率和品質，更實作了快速回應和版本控制等關鍵功能，也讓 CI/CD 與 DevOps 的融合成為可能。本文將探討如何利用自動化工具提升軟體交付速度和品質，同時也將探討許可權管理的重要性，並以 GitLab CI/CD、Jenkins 和 GitHub Actions 等主流工具為例，解析其在實際專案中的應用。最後，本文將探討如何從傳統的瀑布式開發流程轉型到 DevOps，並分析轉型過程中可能遇到的挑戰和應對策略。

自動化工具優勢

在 DevOps 與 CI/CD 的興起之前，「手動封裝及佈署」無論對於大型企業或中小型企業都帶來極大挑戰與瓶頸。「手動封裝」與「手動佈署」本身就是一項高度專注力及精準度所需要才能完成之任務，「手動封裝」除了需要深入瞭解如何進行編輯檔案及設計模組之外還需要懂得如何封裝成適合傳遞給客戶端格式之外還需要懂得編寫指令碼及作業系統指令去處理要如何透過網路把檔案成功傳遞給客戶端。「手動佈署」則除了需懂得透過網路把檔案成功傳遞給客戶端之外還需懂得如何去解決所有沒有相容性問題及測試安全漏洞等所有必要步驟。

玄貓認為「自動化工具優勢」主要是以下幾點：

  1. 提升效率：自動化工具可以快速地進行重複性高且標準化程度高之工作流程。
  2. 提升品質：透過自動化工具可以減少人為因素造成之錯誤且提升整個工作流程標準化程度。
  3. 快速回應：自動化工具可以隨時快速回應並解決問題
  4. 驗收管理：自動化工具可以快速驗收管理所有版本資訊及檔案

玄貓認為「未來趨勢」主要是以下幾點：

  1. 自動化程度提升：隨著時間過去未來每個公司會更加註重如何提升自動化程度。
  2. 安全性管理：隨著未來公司資料更加敏感更加需要注重如何透過自動化工具來提升安全性管理。
  3. CI/CD 與 DevOps 融合：隨著時間過去未來 CI/CD 與 DevOps 融合將會成為未來每個公司所必備之標準之一。
  graph TD;
    A[CI/CD] --> B[DevOps];
    B --> C[自動化];
    C --> D[效率提升];
    C --> E[品質提升];
    C --> F[快速回應];

許可權管理

從上圖中我們瞭解了『CI/CD 與 DevOps 融合』是未來每家公司標準之一，「許可權管理」也是我們要注意之重點之一。許可權管理主要分為「存取許可權」、「管理者許可權」、「編輯許可權」三種分類別。

  1. 「存取許可權」主要負責管理所有『誰』可以『存取』『哪一台伺服器』及『哪一筆資料』。通常大家都認為「存取許可權」就是負責控制『誰』可以存取某台伺服器及某筆資料。「存取許可權」也同時負責控制『誰』可以傳輸某台伺服器上的某筆資料給其他同事。「存取許可權」之所以如此重要原因是因為如果某位同事被誤放入了『存取許可權』可能會造成公司機密外洩。
  2. 「管理者許可權」主要負責管理所有『誰』可以『管理』『哪一台伺服器』及『哪一筆資料』。通常大家都認為「管理者許可權」就是負責控制『誰』可以管理某台伺服器及某筆資料。「管理者許可權」也同時負責控制『誰』可以傳輸某台伺服器上的某筆資料給其他同事。「管理者許可權」之所以如此重要原因是因為如果某位同事被誤放入了「管理者許可權」可能會造成公司機密外洩甚至直接被刪除該台伺服器上的所有資料。
  3. 「編輯許可權」主要負責管理所有『誰』可以『編輯』『哪一台伺服器』及『哪一筆資料』。通常大家都認為「編輯許可權」就是負責控制『誰』可以編輯某台伺服器及某筆資料。「編輯許可權」也同時負責控制『誰』可以傳輸某台伺服器上的某筆資料給其他同事。「編輯許可權」之所以如此重要原因是因為如果某位同事被誤放入了「編輯許可權」可能會造成公司機密外洩甚至直接被刪除該台伺服器上的所有資料。
  graph LR;
    A[系統] --> B[存取許可權];
    A --> C[編輯許可權];
    A --> D[管理者許可權];

自動化工具實際應用案例

以下為玄貓提供實際應用案例：

  graph TD;
    A[自動化工具] --> B[GitLab];
    A --> C[Jenkins];
    A --> D[GitHub Actions];
    A --> E[Bitbucket Pipelines];
案例1 GitLab CI/CD

GitLab 提供了一系列 CI/CD 功能，讓開發人員可以自動化地進行測試、構建和佈署流程。以下是 GitLab CI/CD 的基本步驟：

  1. 建立 .gitlab-ci.yml 檔案：在你 GitLab 專案中建立 .gitlab-ci.yml 檔案，定義你希望自動執行的各種任務。
  2. 定義測試階段：在 .gitlab-ci.yml 檔案中定義測試階段（例如單元測試、整合測試等）。
  3. 定義構建階段：定義構建階段以編譯和封裝應用程式。
  4. 定義佈署階段：定義佈署階段以將應用程式佈署到各種環境（如開發、測試、生產）。
  5. 觸發管道：當你推播更改到 GitLab 倉函式庫時，GitLab CI/CD Pipeline會根據 .gitlab-ci.yml 檔案中定義的步驟自動執行。
內容解密：
  1. 建立 .gitlab-ci.yml 檔案：GitLab 的 CI/CD 組態檔案 .gitlab-ci.yml 是核心檔案，它定義了整個 CI/CD Pipeline中的各個階段和步驟。這個檔案使得 GitLab 能夠理解如何進行自動化構建、測試和佈署。
  2. 定義測試階段：在 .gitlab-ci.yml 中定義不同型別的測試階段（如單元測試、整合測試）以確保應用程式在不同層面上都能正常執行。這樣可以早期發現並修復潛在問題。
  3. 定義構建階段：構建階段包括編譯和封裝應用程式。這步驟通常涉及使用特定語言或框架提供的一些工具（如 Maven、Gradle 或 Webpack）來生成最終版本或執行檔案。
  4. 定義佈署階段：在 GitLab 中定義不同環境（如開發、測試、生產）下需要執行何種操作以完成應用程式或服務的一致安裝或更新流程；例如包括排程快照檔案上傳至遠端伺服器或指令碼執行等；
  5. 觸發管道：GitLab CI/CD Pipeline由版本控制系統中的更新觸發。當開發人員推播更改到倉函式庫時，GitLab 會根據 .gitlab-ci.yml 中組態好的步驟自動執行相應操作；從而實作自動構建測試與釋出。
案例2 Jenkins

Jenkins 是另一款強大且靈活的 CI/CD 工具。以下是 Jenkins 的基本步驟：

  1. 安裝 Jenkins：首先安裝 Jenkins 在你選擇的平台上。
  2. 建立 Jenkins Job：在 Jenkins 中建立一個新專案（Job），選擇適當型別（如自由風格專案）。
  3. 組態原始碼管理：組態 Jenkins Job 的原始碼管理設定（如從 Git 或 SVN 拿取）。
  4. 新增構建步驟：新增構建步驟以編譯和封裝應用程式。
  5. 新增後處理步驟：新增後處理步驟（如通知電子郵件）。
內容解密：
  1. 安裝 Jenkins：Jenkins 是開源軟體, 安裝過程十分簡單, 每個平台均有其對應安裝；其中包括 Windows/Mac/Linux 各種發行版本, 在企業級應用中通常選擇 Linux 作為執行環境；此外安裝過程還涵蓋一些基本設定, 比如埠號與 SSL 組態等；
  2. 建立 Jenkins Job：Jenkins 中建立專案即建立 Job, Job 是 Jenkin 構建Pipeline核心單元, 包含了構建指令碼與執行階段；不同型別專案有不同功能設計, 比如自由風格專案具有高度靈活性, 而多分支專案則專門針對多分支開發進行最佳化；
  3. 組態原始碼管理：Jenkins 支援多種版本控制系統(Version Control Systems), 包括 Git/SVN/Mercurial等；透過組態版本控制系統, Jenkins 能夠實作從遠端倉函式庫提取最新程式碼, 配合後續構建與測試階段；
  4. 新增構建步驟: 在 Jenkins 中, 構建階段指的是將原始碼轉換為執行時環境下執行所需檔案；具體構建過程因語言與框架而異, 比如 Java 專案通常會倚賴 Maven/Gradle 作為構建工具；
  5. 新增後處理步驟: 一旦構建完成, Jenkins 支援設定後處理步驟以釋出結果或通知; 常見後處理包括將構建產物上傳至遠端倉函式庫, 或透過郵件/即時訊息/Slack/微信等方式傳送通知;
案例3 GitHub Actions

GitHub Actions 提供了一系列強大而靈活地進行 CI/CD 自動化操作能力; 指令碼僅需直接編寫於倉函式庫中的 .github/workflows/ 路徑下即可實作: 在該目錄內建立 YAML 原始檔(如 main.yml)來定義工作流程(Wokflow); 每一個工作流程由事件(events)觸發執行: 每次推播新程式碼或者建立提取請求時均會觸發對應 Workflow;

內容解密：
  1. .github/workflows: 在 GitHub 上建立新專案時會預先創好 .github/workflows 路徑作為預設路徑; 使用者只需在此路徑下編寫 YAML 原始檔來觸發對應事件; 特別地 .github/workflows/main.yml 是預設主工作流程路徑;
  2. YAML 原始檔: YAML 是輕量級資料序列化標準語言; GitHub Actions Workflow 中每一個引數皆透過 YAML 組態方式來實作; 工作流程內每一個引數透過標準符號": “分隔並結合縮排格式來表示: 比如: name 和 on 引數分別表示該工作流程名稱與觸發方式; jobs 引數則表示該 Workflow 包含何種任務並指明執行條件; 3.事件(events): 在 workflow.yml 中 on 引數指明觸發條件: 比如 push/pull_request/events/types/commit/push_tag/release等都為常見觸發事件; 每當發生對應事件時均會觸發 Workflow 自動執行;

主題標題：軟體開發生命週期中的手動實踐挑戰

段落標題：手動軟體開發生活週期的困難

在軟體開發生命週期（Software Development Life Cycle, SDLC）中，許多工通常是手動完成的，有些可以部分或完全自動化。然而，無論選擇哪種方法，都會遇到一些問題，這些問題可能會讓每個任務成為潛在的痛點。讓我們來探討手動完成這些任務所面臨的困難。

次段落標題：時間成本

手動任務通常需要大量時間，即使你已經有過手動完成這些任務的經驗。事情總是會出錯，這些錯誤需要耗費大量時間進行排錯和修復。即使一切順利，每個任務本身也涉及大量工作。這裡要提到的是1979年物理學家道格拉斯·霍夫施塔特提出的法律：事情總是比你預期的更久，即使你考慮到霍夫施塔特法則。

次段落標題：易出錯

由於這些任務依賴人為操作——而人類可能會疲勞、厭煩或分心——因此容易出現組態錯誤、資料輸入錯誤或遺漏步驟等問題。這些人為錯誤會導致事情出錯。

次段落標題：員工士氣

沒有人喜歡做例行性、重複性的工作，特別是在高風險情況下必須確保正確無誤時。對於品質保證工程師來說，連續兩週內第20次執行標準2小時的手動測試，可能會讓他們懷疑是否選擇了錯誤的職業。

次段落標題：溝通與報告風險

當手動測試者完成了他們那令人窒息的2小時測試套件後，他們是否還有足夠的腦細胞準確地記錄哪些測試成功了、哪些失敗了？所有這些測試都將毫無意義，如果我們不能依賴結果被準確記錄。任何人在執行困難的手動測試計劃時都知道結果中有多少模糊之處、有多少意外條件可能會影響測試結果，以及如何向依賴那份報告的人解釋這些因素是多麼困難。甚至沒有考慮到簡單地記錄結果錯誤的巨大可能性。

段落標題：DevOps 之前的世界

如果我們描述的一些任務可以自動化，那麼這樣做會消除我們在手動任務中面臨的問題嗎？自動化確實能解決一些問題，但向 SDLC 新增一系列自動化工具將引入一整套新的問題。考慮一下執行此操作所涉及的額外努力和成本以及構建自定義工具鏈所涉及的任務：

次段落標題：工具選擇與整合

  1. 為每個可自動化的任務研究和選擇工具。
  2. 為每個工具購買和更新許可。
  3. 為每個工具選擇託管解決方案。
  4. 為每個工具組態使用者。
  5. 學習每個工具的不同圖形使用者介面（GUI）。
  6. 管理每個工具的資料函式庫和其他基礎設施。
  7. 將每個工具與 SDLC 中的其他工具整合。
  8. 嘗試將每個工具在中央位置顯示狀態和結果（如果可能）。

次段落標題：維護與更新

  1. 處理有缺陷、過時或不再吸引人的工具。

即使解決了手動或自動化任務所帶來的所有問題，仍然有一個無法避免的大問題存在於使用此模型的團隊中：它是順序工作流程。步驟一個接一個地發生。一個團隊編寫軟體，然後將程式碼扔給另一個團隊進行構建。那個團隊又將程式碼傳遞給第三個團隊進行驗證。當他們完成後，通常會將其傳遞給另一組負責安全測試的工程師。最後，釋放團隊獲得它以便將程式碼佈署到正確位置。有很多方法可以使此過程偏離基本描述，但執行一步接一步並且只在前面步驟完成後才將程式碼傳遞給下一步是許多軟體開發團隊工作流程分享的一種特徵。

目前可能不太明顯的是順序工作流程帶來了什麼問題。由於手動執行這些步驟或讓自動化步驟在多個工具中平穩可靠地執行所帶來的困難，此工作流程通常只偶爾發生。程式碼透過這些步驟執行的頻率因團隊而異，但所需時間和成本意味著程式碼更改通常會堆積積幾天、幾週甚至幾個月才能正確地構建、驗證、保護和佈署。而這又意味著在該過程中檢測到的問題成本高昂。如果功能測試失敗、安全測試檢測到漏洞或整合測試顯示程式碼佈署後無法正常運作，那麼確定導致問題的是哪段程式碼就像在很大的一堆積草裡找針。

如果5,000行跨越25類別的程式碼已更改、16個依賴項升級到更新版本、Java版本從版本16更改為版本17以及測試環境執行於Ubuntu不同版本等情況出現時，要追蹤問題來源並解決問題就會變得非常困難。

主題標題：從水管式轉向 DevOps 的必要性

段落標題：水管式工作流程中的挑戰

傳統軟體開發常見的是水管式（Waterfall）工作流程，即每個階段依序進行且彼此獨立。雖然這種方式在過去曾經被廣泛採用，但隨著技術進步與市場需求變化，其弊端逐漸顯現：

次段落標題：順序工作流程導致效率低下

由於手動執行或管理自動化步驟所帶來困難以及維持多工具平穩可靠運作所需時間和成本等因素影響下，使得順序工作流程通常僅間歇性地發生。

主題標題：DevOps 的優勢與挑戰

段落標題：DevOps 的應運而生

DevOps（Development and Operations）旨在打破傳統水管式開發模型中的壁壘，強調開發（Development）與維運（Operations）之間緊密合作及持續交付（Continuous Delivery），以提升軟體交付速度及品質。

次段落標題：DevOps 的優勢

DevOps 的核心價值包括：

  • 快速交付：透過持續整合（CI）與持續交付（CD），減少了新功能上線所需時間。
  • 高效協作：開發與維運團隊之間緊密合作，減少了溝通摩擦並提高了問題解決效率。
  • 提升品質：透過自動化測試與監控系統，降低了人為錯誤並提升了系統穩定性。
  • 靈活應對市場需求：能夠迅速回應市場變化並推出新功能或修復漏洞。

次段落標題：DevOps 的挑戰

儘管 DevOps 帶來諸多好處，但其實施過程中也存在挑戰：

  • 文化變革：需要企業內部文化轉型及員工技能提升。
  • 技術整合：不同技術之間協同運作需求較高。
  • 安全風險：持續交付模式下安全管理需求更高。
玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。