軟體上線流程中有哪些階段?

除了寫程式外，軟體工程師在完成程式後，也需要將程式部署。在這篇文章中，我們將會完整走過軟體開發的上線流程，讓身為軟體工程師的你，能確保把關好團隊的上線流程。

在完成開發之後，多數軟體開發團隊會有以下的上線流程 (備註：多數團隊不會走過下面提的所有流程，所以實際要跑哪些流程，還是以你所在的團隊的規範為主)

開發

在完成技術設計後，團隊會進到開發階段，這時會在開發環境 (Development Environment) 進行。多半這時會是在本地進行，不過近年來許多雲端 IDE 越做越好，也逐漸有在雲端環境進行開發。

內部測試

在完成開發後，會先在內部進行測試，這時會進到內部測試環境。內部測試一般會分成兩種，一個是 Alpha 測試，另一個是狗糧測試 (dogfooding)。

1. Alpha 測試 所謂的 Alpha 測試，是在開發完後，由開發者自己測試，或是請團隊中的 QA 來協助測試。Alpha 測試的目的，是要確保要上線的功能都如預期，同時既有的功能沒有被影響，藉此來確保軟體的穩定性。測試過程通常會涵蓋所有的功能，模擬使用者操作軟體的行為，來確保功能都沒有問題。

2. 狗糧測試 (dogfooding) 在 Alpha 測試後，接著會進到狗糧測試。所謂狗糧測試是指讓內部員工自己使用，自己從使用者的角度來試產品，藉此來搜集問題。舉例來說，在 《Threads 團隊如何開發這款史上最快達成一億註冊的產品》一文中，我們談到，Threads 團隊在產品開發更趨於完整後，開給整個 Instagram 團隊來做狗糧測試，並從其他人的使用過程中蒐集回報的問題。 之所以叫狗糧測試，是出自於多年前微軟的 Paul Maritz 寄送一封給軟體測試主管的信件中提到 Eating our own Dogfood (吃我們自己的狗糧)，藉此來比喻自己開發的產品，自家員工要自己用過。

   這種把自己當使用者來測試的方法，不僅能幫忙抓出許多問題，也能從中獲得一些對產品的洞見。因為這個做法非常有效，吃自己的狗糧逐漸演化成一個業界常態的做法，時至今日被稱為狗糧測試 (dogfooding)。

模擬環境測試

由於在內部測試時，各種環境變數或設定，不必然跟真實線上環境相同。許多時候這樣做是為了做隔離，確保在測試環境做測試時，不會影響到線上的環境。因此，在測試環境的測試都完成後，會進一步到模擬環境 (Staging Environment) 做測試。模擬環境顧名思義是在模擬正式的生產環境，確保各面向都沒問題，不會因為不同的環境變數、依賴等因素改變，導致軟體無法如預期運行。

Beta 測試

在模擬環境測試完成後，接著會進到 Beta 測試。Beta 測試有兩種，一種是封閉的 Closed Beta，就是大家常聽到的封測；另一種是公開的 Open Beta，就是大家常聽到的公測。不論是哪一種，在 Beta 測試時，不僅是環境會模擬正式環境，還會真的邀請外部使用者來。

雖然僅會邀請少數使用者，Beta 測試仍很有價值，因為通常在有外部使用者參與測試，能協助系統找到更多潛在的問題 (畢竟許多時候，使用者在用產品時，可能會有各種讓人意想不到的方式)，同時也能給予產品回饋，協助產品迭代。

金絲雀 (canary) 部署

在前面的各種測試階段都完成後，接著就要正式將軟體部署上線。而在部署上生產環境時，一般來說會分階段上線，而不是一次全上，例如 10% 後 30% 然後 50%，最後 100%。會這麼做是因為從小流量開始上線，能夠確保如果真的不小心出問題，只會影響到新上線的部分。例如在 10% 流量時，就發現問題，那這樣影響的範圍只會是那 10%。這種分小流量來避免出問題時影響過大，是金絲雀部署的優點之一。

你可能會好奇，為什麼要叫金絲雀部署? 這個命名是源自早年礦場為了確保礦坑沒有毒氣，在礦工實際進入礦坑前，會先放金絲雀去探勘，假如金絲雀能順利飛回來，代表礦坑沒有毒氣；反之，如果金絲雀沒有飛回來，那估計因為礦坑中的毒氣導致金絲雀死亡，這時礦工團隊就知道不該繼續往下挖礦。

而對應到程式碼的部署，金絲雀部署就像放出金絲雀，先以金絲雀去探勘，而不是直接全量上線，這樣遇到問題的話，也只有前面有被放出的小流量會被影響，而不會造成過於巨大的損失。在早期許多團隊也會用一種叫藍綠部署的方式，也是先有測試後，直接把所有流量都切到最新的版本。然而這種方式的靈活性相對低，因此目前業界更偏向金絲雀部署。

A/B 測試

現代軟體團隊，在做小流量的部署時，多半會搭配 A/B 測試來進行。Spotify 團隊先前分享，他們使用的流程，會是用功能切換 (feature toggle) 的形式進行 (詳見此文)。一開始只切換開給有特定標示的使用者可以用到新功能，例如在內部測試階段，新功能的流量只會打到帶有內部人員標示的使用者。

接著再逐步放量，例如 20% 的流量的使用者會進到新功能的流量。而這 20% 會是以隨機的方式，確保能夠同時來跑 A/B 測試，如果實驗的結果有符合預期 (例如新功能帶來更好的效果)，在 A/B 測試時會逐步放量直到 100%；反之，如果新功能不符預期，在實驗階段就會先終結，不繼續做全量的放量。

全量上線

在走過上面的完整流程後，新的產品或功能就到全量上線的階段。然而這階段不代表結束，因為全量上線後，仍要保持對產品與系統的監控，以確保發生問題時，能夠即時響應並解決。

與此同時，要確保跟進並獲得成果，這點不論對績效考核，或者對於未來找新工作，都很重要。過去我們遇到非常多讀者，在找工作時履歷只能寫做了什麼，但是寫不出做的事情的影響力，這往往是因為沒有去追蹤上線後的收益。

閱讀更多

在談完以上的流程，接下來我們會進一步談在上線過程中要特別注意的事、避免踩到的誤區。 這些點我們在 E+ 成長計畫的主題文都有更詳細談到，推薦感興趣的讀者閱讀。

本文為 E+ 成長計畫的深度內容，截取段落開放免費閱讀。歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)。