前言

在實際採用任何一種方法學之前 , 其中一件很重要的事就是要理解這些方法背後的理念與哲學 , 不然 , 往往流於形式而不得其精髓 。「 持續交付 」 的概念對很多人來說還算陌生 , 本文分享的就是 「 持續交付 」 最重要的 8 條原則 。

持續交付理念

1. 部署 / 發佈軟體的流程 「 必須 」 可重複且可靠

這條原則其實也就是 「 持續交付 」 的目標 , 實現 「 持續交付 」 的最終目的就是要讓軟體發佈不再是個冗長 、 靠運氣的事情 。 有參與手動軟體部署經驗的人 , 常常會發現不是每一次部署都會成功 , 而且每次出錯的原因可能都不太一樣 ! 在有點規模的網路服務公司 , 系統的部署通常由營運團隊負責 , 雖然營運團隊會將部署的流程與步驟文件化 , 但由於軟體持續在更新 , 文件很快就過期 ; 或者 , 部署的過程漏掉一個步驟 , 往往導致部署耗費過長時間甚至部署失敗 。

2. 全面自動化

您也許運氣好 , 遇到可以可靠部署系統的團隊 , 但是如果每次部署都要耗費過長時間 , 同樣是需要解決的問題 。 不要忘記 : 開發出來的軟體功能 , 在還沒有送達用戶 ( 發佈到生產環境 ) 手上之前的等待時間都是一種浪費 ! 既然軟體部署應該是個 「 可靠 」、「 可重複 」 的流程 , 那麼就沒有理由不將它自動化 。 山姆鍋常常會跟成員強調 :「 在軟體開發營運的流程中 , 只要發現有件事情需要重複作 , 那麼就要考慮自動化的可能 」。 可以說 ,「 自動化 」 是讓團隊將時間運用在更重要任務上的必要手段 , 同時也是小團隊要能夠管理大系統的重要策略 。

3. 假如覺得某件事困難或者痛苦 , 那就重複頻繁地作到駕輕就熟

不喜歡運動的人都會覺得慢跑是件很痛苦的事情 , 想要克服這種痛苦養成慢跑的習慣的唯一方法 : 就是持續不間斷地每天慢跑 ! 當然人都有逃避或延後讓自己覺得痛苦的傾向 , 但在軟體開發上 , 逃避問題只是讓它更加惡化到難以管理的層度 。 例如 : 將原始碼某個分支 (branch) 合併到主線通常是件麻煩事 , 如果沒有特別要求 , 軟體工程師會傾向於慢點進行整合 , 但客觀來說 , 我們知道越後面才進行整合其難度越高 。

簡而言之 , 藉由重複頻繁地操作整個過程 , 讓流程中的瓶頸儘快浮現後改善 , 從而提升整體流程的效能與可靠性 。

4. 一切都要進行版本控制

「 版本控制 」 是讓軟體發佈流程可以重複的根本依據 。 作為組態 / 配置管理 (configuration management) 的一環 , 不止是程式碼需要版本控制 , 要做到從發想 (idea) 到實現過程中 , 需要被記錄與維護的東西 , 都需要進行版本控制 。 從需求文件 、 設計文件 、 程式碼 、 或者虛擬機的設定規格 , 到實際部署的腳本等 , 只要是完成軟體交付所需要的文件 、 資料 、 設定或者程式碼都要是版本控制的範圍 。

可以說 , 版本控制是讓軟體發佈成為可靠且可重複的前提 。 如果團隊無法知道目前部署到某個環境的軟體版本是什麼的話 , 那麼幾乎可以確定這個團隊也無法做到可靠的部署要求 。

5. 只有 「 發佈了 」 才算完成

如果 10 個軟體工程師跟您說某個功能寫好了 , 其中大概有 9 個意思都是指 : 「 程式已經寫好且在他的開發環境可以正確執行 」。 在 「 精實生產 」 的觀念裡 , 只要軟體 / 產品還沒有交付到最終用戶的手中就不算完成 ! 同樣地 , 「 持續交付 」 對於 “ 完成 ” 的定義也是希望發佈到生產系統 (production system) 才算數 。 不過 , 每個軟體專案的情形不盡相同 , 有些團隊也許可以採用不同的準則 , 例如 : 在一個類似生產環境中可以被示範 (demo) 就算完成 。 這點跟 Scrum 這種敏捷開發方法相同 , 並沒有絕對硬性規定 。

6. 內建品質

假設達到持續交付的目標 , 但軟體的品質卻不被接受 , 這樣可說是本末倒置 。 傳統上 , 有許多人會誤解確保軟體品質是 QA 團隊的責任 ; 或者更糟糕的想法 : 不確保自己寫的程式的正確性 , 依賴 QA 是否發現問題再來修正 。 品質是所有參與整個開發的成員的共同責任 , 不管負責是產品規劃 、 設計 、 開發 、 測試 、 部署還是客戶服務 , 每個人都要共同承擔品質的職責 。

要達到 「 持續交付 」 的目標 , 需要實施相關技巧來確保軟體品質在過程中得以被確保 , 像是 :「 單元測試 」、「 整合測試 」、「 煙霧測試 」「 效能測試 」、「 用戶接受性測試 」 等 。 記得第 3 條原則 :「 全面自動化 」 嗎 ? 這些測試要以自動化的方式執行 。

7. 每個人都有責任參與交付流程

由於每個參與的成員對於最終軟體的品質都有責任 , 自然就有責任參與整個交付流程 。 軟體交付包含的不止是軟體部署而已 , 從最原始的想法 (idea), 到實現 (implementation), 再到實際部署 (releasing), 每個環結只要出錯 , 就會影響到整個流程的進度 。 為了強調這點的重要性 ,「 精實生產 」 甚至在流程出現問題時會讓整個流程暫停 , 直到找到問題且確保同樣問題不會再發生才恢復 。

由於這樣的觀念 , 慢慢地有所謂 「 DevOps」 的形成 。 組織上 , 不再是一個個不同功能的團隊 , 而是傾向於以跨功能 (cross-functional) 的小團隊為主 。 是誰說 : 軟體工程師不能做 QA 的工作 ? QA 工程師就不用寫程式嗎 ? 況且 , 現在連系統營運都需要像 Puppet 這種需要寫腳本的自動化工具協助 , 其實很難再以寫程式與否來分別開發 、 測試與運營工程師了 !

8. 持續改善

「 持續交付 」 不是可以一蹴可及的目標 , 制度跟流程也不是一夕間就能改變 , 就算像 「 影化身科技 」 這種新成立的公司也一樣 。 制度 、 方法 、 流程與工具的評估 、 確立與實現都需要不斷地實驗與調整 。

結語

「 持續交付 」 可以說是個很高的理想 , 當然也不是個容易達到的目標 。 但有了目標才可以作為實踐過程中的指導方針 , 也才不至於過於關注單一的環節 。 山姆鍋認為 「 精實生產 」 要求的是整體流程的持續改善 , 「 持續交付 」 則是達到 「 精實生產 」 的手段之一 。