「沒有持續交付（Continuous Delivery），專案不得上線，我不是在說笑。」雅虎（Yahoo）執行長Marissa Mayer的宣言，在雅虎內引起一陣軒然大波。
-400.png)
雅虎執行長Marissa Mayer強推持續交付，宣示沒有導入持續整合的專案不得上線。（圖片來源／Adam Tinwort）
2014年下半年，雅虎打算全面導入持續交付，Marissa Mayer還對全公司發出這個強硬宣示，不只雅虎美國團隊，連全球各地、日本、臺灣的亞太研發團隊的開發流程都面臨了全新的大衝擊。
甚至為了導入持續交付，光是前期準備工作，雅虎就分成兩階段來進行。第一階段是在30天內，將1,800多個使用集中版本控制軟體SVN管理的程式碼儲存庫，轉移到分散式版本控制系統Git上。
第二階段則是在30天內，將雅虎總共130座的Jenkins farm，集中規模到4座。而這些Jenkins farm目前一天總負責超過4萬項的工作及應付6.5萬次的Build，雅虎資深工程師應百怡表示，光是持續交付準備階段，雅虎都設定了這樣非常有野心而且大膽的目標。
不少雅虎員工得知後紛紛發出抱怨，甚至為執行長的宣言感到憤怒，認為為了進行中的專案，已經忙得焦頭爛額，卻還要為導入不熟悉的作業流程拖累進度。有工程師的第一個反應：「全面導入持續交付？我們團隊的專案應該不包含在內吧。」連雅虎測試工程師都質疑，怎麼可能在短時間內將3萬個手動測試全部自動化。
另外，亦有團隊開始尋求折衷方案，希望手中負責的專案可以進行例外處理。但是，面對這些內部反對的聲音，Marissa Mayer堅守著她要走的路，對雅虎全面導入持續交付的態度沒有鬆動。
雅虎還沒導入持續交付時，應百怡表示，一開始工程師完成專案開發後會交由測試工程師測試，而此過程將會重複多次，直至產品品質達到一定水準。而當專案進行至預期釋出一周前，雅虎會召開會議，決定是否要將產品釋出。與會者則包含工程師經理、測試工程師經理、服務工程師等人，討論系統中的各個元件釋出的順序。
而在釋出日當天，雅虎會將專案參與者集中在一室，或是使用IRC確保所有人都隨時掌握目前產品釋出的進度。而釋出結果總是一翻兩瞪眼，應百怡表示，不是產品成功釋出，團隊歡喜慶祝，就是失敗回到原點所有過程重新執行一次，不僅要耗費心力將專案關係人召集起來，而且這種釋出模式也對團隊成員造成相當的情緒壓力。應百怡表示，過往沒有導入持續交付時，「此種工作模式一個月只能釋出一次」，無法支撐頻繁釋出的工作流程。
領導團隊定義統一用詞以及準則，協助員工上手新工作模式
應百怡表示，而為了快速得到使用者回饋，迅速對產品做出修正，雅虎勢必要改變工作步調，加速產品釋出頻率。此外，領導團隊也統一雅虎內持續交付的詞彙，方便團隊間的溝通。
應百怡舉例，雅虎每個部署的單位稱為包裹（package），而一到多個包裹則組成映像（image）。映像則會部署於主機上，而主機群則稱為元件，而如果多個元件要釋出，就會稱為系統。
在Marissa Mayer喊出「沒有持續交付，專案不得上線」的口號後，她還特別成立了負責持續交付的領導團隊，來引導其餘全公司各部門的研發團隊如何順利導入持續交付。
由這個領導團隊來制訂規則，確保持續交付的工作流程圖符合內部規定。而雅虎的規定是每次的建置一定要符合可重複性及可重現性。應百怡表示，可重複性的規定為，某次的產出若部署到某臺機器上，不論部署幾次，產出結果都必須一致。而可重現性則是某次的產出，在不同的機器上部署，產出的結果也應該一致。此外，每次團隊的產出都要有版本序號，如果程式碼有改變就必須有新序號出現，方便追溯每個版本間的差異。
另外，所有的程式碼都必須使用版本控制系統，如原始碼、發行腳本、測試檔案及測試碼。不過，即使領導團隊訂出了規則並且給予許多協助，「每個團隊仍然要思考如何執行以及導入持續交付。」應百怡表示。
每個事業單位也必須定期與領導團隊開會，回報進度以及報告專案上碰到的問題。而領導團隊也要訂定與持續整合相關的作業準則，或是提供案例給事業單位做參考，「這些都是雅虎成功導入持續交付的重要元素。」應百怡表示。而領導團隊統一內部持續交付的詞彙以及訂定工作規則的做法，都擴大工具的範疇，讓工具不再局限於軟體。
不過，導入持續交付的過程也不是一帆風順，應百怡表示，常常非技術背景的員工對持續交付產生誤會，以為要排除人為干涉便略過中間程式碼測試階段，直接進入線上環境。此時必須與他們解釋，流程中的測試流程仍然都存在，但是變成自動化執行。
此外，測試工程師也會提出質疑，是否要在短時間內將3萬個手動測試全部自動化？而應百怡表示，並非如此。當手動測試的項目越多而單元測試越少，如此的工作流程並沒有效率。她表示，正常的測試流程，單元測試所占比例應為最多，依序為整合測試、端對端（End to end）測試，而手動測試則占最少比例，如此的測試流程才有意義，並且進行快速。
領導團隊為了加強員工對持續交付印象，也印製許多文宣、海報，無時無刻宣傳執行長所交付給雅虎員工的任務。而透過領導團隊種種教育以及洗腦，持續交付終於在雅虎內成為普遍共識。一開始，應百怡認為導入持續交付應該很輕鬆，沒想到過程卻如此艱辛。她表示，因為每個團隊都有自己產品釋出的流程，而在導入持續的過程中，除了把人工作業改為自動化外，勢必會碰到許多變化。
此外，導入持續交付的成本也會取決於專案的複雜度跟歷史長度。她表示，從頭開始的新專案要導入持續整合相較容易，但是雅虎許多的系統與產品大多都是存在已久，所以付出的導入成本相當高。
導入持續整合，兼顧釋出速度與品質並非不可能
然而，時常有人質疑，快速的釋出頻率與品質是否不能同時兼顧，必須要在兩者中做抉擇？應百怡表示，其實仍有辦法同時顧及兩者。例如，如果專案的規模龐大而複雜，可以將專案劃分為多個小型專案，批次釋出或是導入自動化流程。
應百怡表示，如果專案採取少量而多次的模式釋出，團隊可以很快地發現產品問題，並且迅速進行修改，讓整體反應時間加速，「釋出階段發現問題並不是件壞事，因為發現錯誤並且迅速修復，對於品質其實是正向幫助。」她也表示，少量的釋出也能確保程式碼如預期中運作。例如，檢查10行程式碼錯誤的難度，相較1,000行程式碼低得多。
此外，導入自動化流程也可加速釋出速度。她舉例，如果測試是以人力進行，不僅速度較慢，過程中也可能因為牽扯到人為因素而出現錯誤。
應百怡表示，導入持續交付後，除了改變既有工作模式外，團隊也都有相關正面的回饋。例如，由於測試的重要性提升，開發團隊轉而開始先著手撰寫測試，因為產品如果未經測試直接進入線上環境，可能會得到不理想的結果。
而每次少量的釋出，除測試工程師很快抓到測試目標外，因為釋出品質更加穩定，少了許多突發事件，服務工程師也可從事更有產值的工作。最後，產品負責人亦可以更快看到使用者對於產品設計的回饋。所以，「持續交付不只是工程上的策略，雖然主要由工程團隊主導，但是受益者絕對包含整個公司。」應百怡表示。
不過，速度只是持續交付的一部份，如果只有做到快速交付軟體，讓工程團隊以及專案經理感到高興還不夠，「持續交付的重點是同時快速交付軟體跟傳遞價值。」她表示。
應百怡舉例，假如開發團隊的目標使用者目前需求必須要被解決，而傳統沒有導入持續交付的團隊，也許花了數個月的工作時程，卻交付使用者不需要的服務，進而造成人力與時間的浪費。
然而，在產品釋出後必須經過多次的測試、反覆上市的過程，才會釋出好的產品。所以，雅虎導入持續交付的目的便是確保在每個工作週期中都可以交付價值，讓產品可以兼顧品質跟釋出速度。
雖然工具在導入持續交付中占有一定程度的重要性，但是工具的選擇多如毛牛，也不可能期待蒐集到所有的完美工具後，才開始導入持續交付，反之，即使你中意的工具不完美，也可導入持續整合的流程。應百怡表示，導入持續交付的過程中，人其實最重要，而人的重要性在於思維方式改變後，也會進一步的影響公司文化，如雅虎最初導入時，雖然引起員工的反彈，但是到了現在，「如果知道哪個專案沒有導入持續交付，大家會倒抽一口氣」，她表示。
應百怡表示，雅虎有一位懂持續交付的優點並且強力推行的執行長，是件幸運的事情。因為非技術背景的員工較難理解持續整合的優點，只覺被交付額外的工作而心生不滿。如果沒有Marrisa Mayer的強力捍衛，推行持續交付的過程將會碰上更多問題。起初員工可能認為被交付了額外任務，但是若將眼光放遠，「持續交付是幫團隊排除障礙的工具。」應百怡表示。
而事實也證明，Marissa Mayer的堅持是對的，根據雅虎的統計資料，從2014年第三季開始導入持續交付後，全球雅虎釋出的產品增加了4倍以上，而亞太區的表現則更亮眼，釋出產品增加了7倍之多。而持續交付的流程在雅虎內目前導入的比例高達97％，「導入持續交付後就回不去了。」應百怡表示。