2019 年，Shopify 在博客中分享了自己成功合併千名開發人員工作的經驗，並介紹了工具 Merge Queue v2，很多人都好奇為什麼 Shopify 要構建這樣的一款工具呢？
其實答案很簡單，不少企業發展到一定階段後就會遇到這樣的情況。隨著業務發展，Shopify 意識到市面上沒有任何現成的產品可以徹底解決他們面臨的困難。從更長遠地來看，Shopfiy 認為公司應該為開發人員提供儘量完善的開發體驗，並要塑造一種 " 軟件發佈文化 "，所以就開始不斷改進現有的工具鏈和流程方法。
Shopify 是這樣定義企業文化的：
Shopify 所有人信念和行為的總和。
軟件發佈工作是開發工作的子集，自然，" 軟件發佈文化 " 也要和企業文化保持一致。Shopfiy 的軟件發佈工作規範與其他企業沒有太大不同，比如他們要求錯誤的更改不應該流入生產環境，破壞用戶體驗；生產環境中所做的更改不應該犧牲安全性等等。
通往羅馬的道路不止一條，同樣的軟件發佈文化，也有很多可選的實現路徑。Shopify 認為，企業支持團隊應該為開發人員開闢一條路徑，讓他們自由發揮生產力和創造力，並實現自己的目標。企業應該營造一種氛圍，讓版本發佈成為一種勝利時刻。
Shopify 如何評估軟件發佈文化
如何塑造軟件發佈文化？首先要考慮以下問題：
- 開發人員希望選擇怎樣的工作方式？
- 對他們來說哪些事情比較重要？
- 他們如何看待用來支持他們的工具？
- 他們想知道多少幕後信息，想了解多少自己使用的工具背後的知識？
這些問題往往沒有單一的答案，尤其是 Shopify 這家企業中每天參與軟件部署工作的人員眾多，涉及的崗位也多種多樣。Shopify 選擇了一些主動和被動的方法來評估企業內部的軟件發佈文化，這些方法不分先後，它們共同描繪出了一幅關於開發人員如何使用各種工具的圖景。
其中，被動方法主要用來管理和彙總輸入的信息，並不需要企業支持團隊去做很多工作。其中，有一個方法是 開發人員滿意度調查，這是對 Shopify 全公司的開發人員每半年進行一次的調查研究。開發人員需要報告很多信息，比如說他們對自己所使用的工具的滿意度，或者工作中哪些環節非常浪費時間等等。
此外，公司還專門設立了面向所有人開放的 Slack 頻道。在這個頻道上，產品用戶可以從開發團隊或其他用戶那裡獲得支持，並報告他們遇到的問題。Shopify 團隊會積極參與這些頻道的互動，培養社區氛圍並鼓勵開發人員分享經驗。需要注意的是，這些頻道並不是用來獲取產品反饋的主要渠道。
總的來說，他們希望能主動找出產品和服務中的痛點所在，而且意識到了這個過程並不能過分依賴用戶，因此 Shopify 也採取了一些積極的措施來找出最重要、優先級最高的問題。
一種措施叫做 dogfooding。公司內開發團隊用來發布代碼的工具是和構建與維護代碼的工具完全一致的。這樣就很容易找出服務的缺陷所在，並在出現產品問題時站在用戶的視角上理解其影響。
另一項重要資源是 Shopify 的 內部支持團隊。他們需要幫助用戶，還要支持企業內部不斷髮展的工具套件，這是很艱鉅的挑戰。他們需要診斷問題，幫助用戶找到合適的團隊來指導他們解決這些問題。他們能夠找出用戶在當前工作流程中遇到的常見痛點以及概念和原型的潛在問題。
最後，在添加新功能或更改現有工作流程時，Shopify 會在整個過程中實施 用戶體驗研究分析：
- 更好地瞭解用戶行為和期望
- 在開發概念和原型時測試它們
當開發人員發佈 PR 時，團隊會單獨考察開發人員的想法，瞭解他們都在考慮哪些內容，在制定決策時都有怎樣的根據。團隊會與設計師和撰稿人等用戶交流，學習他們的日常工作流程，瞭解他們所依賴的工具和用法。公司會讓實習生和新人測試產品原型，從中瞭解外部和新鮮視角的觀點，並挑戰原有的產品假設。
有了這些流程，企業就能在整個構建和發佈過程中都能從真實用戶那裡獲得一手反饋，進而打造更好的產品和服務。
反饋是一種禮物 在 Shopify 經常提到的一句話就是，反饋是一種禮物。
評估軟件發佈文化的目的是創建一個反饋循環，讓用戶可以輕鬆談論他們遇到了哪些障礙，收到反饋的開發團隊會重視這些意見並嘗試採取對策。
還有很重要的一點是，用戶的反饋會讓產品團隊充滿動力，即便反饋是負面的，這也是用戶重視產品、希望產品變得更好的一種證明，這自然會鼓勵團隊，甚至讓他們在面對困境時振作起來。用戶希望自己的反饋能有價值，這是企業要給用戶營造的氛圍，企業的軟件開發文化和工具鏈應該支持這種良性循環，讓所有人都能從中獲益。
Shopify 的軟件發佈流程
Shopify 的軟件發佈流程是怎樣的形態，又有哪些可以改進的部分呢？
發佈管道
發佈管道路徑
這就是 Shopify 發佈管道的路徑。一開始是拉取請求（PR），然後是持續集成（CI）/ 合併，接著是金絲雀部署，最後是生產發佈。
PR 和 /shipit 命令
這套流程的第一步是開發人員創建 PR，然後在準備交付時發出一條 /shipit 命令。接下來，Merge Queue 系統會嘗試將 PR 與主幹 Master 集成起來。
PR 合併到 Master，金絲雀部署
當 Merge Queue 確定更改可以成功集成時，PR 就會合併到 Master，並部署到 Shopify 的金絲雀基礎架構中。金絲雀環境會隨機接收所有傳入請求的 5％。
更改部署到生產環境
開發人員有一套工具，可以在金絲雀環境中測試更改 10 分鐘的時間。如果沒有手動干預，並且金絲雀自動分析不會觸發任何警報，則更改將部署到生產環境中。
發佈與恢復機制
每一位開發人員都希望能被信任，並對自己的工作擁有自主權。開發人員應該能控制自己 PR 的整個發佈過程。
開發人員控制整個過程
在 Shopify 的軟件發佈流程中，開發人員能控制整個發佈過程。這裡不存在什麼發佈管理器、註銷或者審核窗口。
限制不良更改爆炸半徑的基礎設施
然而是人就會犯錯，出現問題是難免的，Shopify 當然也不例外。為此，公司建立了一套基礎架構來限制不良更改的爆炸半徑。最重要的是，企業相信每位開發人員都應該承擔自己應負的責任，並且如果他們的更改捅了簍子，他們也應該能自己去恢復它。
開發人員可以使用 /shipit--emergency 命令快速跟蹤修訂
一旦準備好了修復程序（修復 - 轉發或還原），開發人員就可以使用一條 /shipit --emergency 命令快速追蹤整個修復進程。Shopify 沒有那麼多恢復協議，而只有一個 緊急狀況 功能，這樣就能讓開發人員以最快的速度完成恢復操作。
快速發佈
開發人員希望快速發佈。
發佈速度是大多數企業應用程序的一個關鍵要素。對於開發人員而言，如果能一天多次發佈代碼並立即將其發送給最終用戶，就能極大提高生產力。但更重要的是，採用快速的發佈流程可以帶來同樣快速的恢復流程。
為了真正加快發佈過程，企業是需要投入資源和成本的。除了專門的基礎架構團隊，Shopify 還管理著自己的 CI 群集，容量高達數千個節點。
自動化
開發人員不想執行重複性的任務。計算機最擅長做重複工作，所以這類工作應該儘可能地自動化。Shopify 在諸如連續部署和金絲雀分析之類的地方實現了自動化。
在 Shopify，開發人員用不著按一個部署按鈕，自動化流程會持續部署到金絲雀和生產環境。
自動化固然很棒，但是某些時候開發人員還是需要手動控制的。在緊急情況下，開發人員可以鎖定自動部署並轉為手動部署。
