我是山姆鍋

在實際採用任何一種方法學之前，其中一件很重要的事就是要理解這些方法背後的理念與哲學，不然， 往往流於形式而不得其精髓。「持續交付」的概念對很多人來說還算陌生， 本文分享的就是「持續交付」最重要的 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. 持續改善

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

結語

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