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

持續交付理念

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

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

2. 全面自動化

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

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

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

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

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

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

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

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

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

6. 內建品質

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

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

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

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

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

8. 持續改善

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

結語

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