作者 | Sergio De Simone
譯者 | 明知山
策劃 | 丁曉昀
DoorDash 公司的移動應用發布流程 基於團隊間明確的分工職責、有效的溝通、測試以及嚴格的回歸問題處理和緊急修復規則。DoorDash 工程師 Manolo Sañudo 解釋說，儘管並非所有的企業都具備 DoorDash 這樣龐大的規模，但他們的解決方案的許多方面對規模較小的企業也有所幫助。
DoorDash 遵循的是相對簡單的周發布周期。每個新的發布候選版本都會有一個發布分支，經過為期一周的測試和修復過程，最終正式發布。
每個新的發布候選版本都會分配一個發布經理來監督整個過程，確保一切順利進行。發布經理的人員池要足夠大，不會出現有人被工作量所拖累的情況，但也不至於過大，以至於無法跨各個發布版本做出一致的決策，或者危及發布流程的發展和改進。
每個發布候選版本都有自己的 Slack 頻道，便於將狀態更新和會話集中到一個地方，防止生產環境的漏洞熱修復產生噪音。
對於測試，Sañudo 表示，由於無法在一周內進行完全的回歸測試，因此「組件所有者」會單獨負責測試所有組件，並使用移動發布管理平台 Runway 來跟蹤測試狀態。
每個組件所有者需要在批准組件之前執行特定的測試任務。在提交評審之前，每個組件都必須得到批准。
Sañudo 表示，在測試階段會不時地發現回歸問題。在這種情況下，發布經理與受影響的團隊合作修復問題，並推送到主開發分支，只有當回歸影響用戶體驗時，這個修復才會被合併到發布候選分支上。在這個階段，既不允許出現對用戶沒有影響的 bug，也不允許添加新特性，每個精心挑選的修復都必須經過團隊的論證，並由發布經理批准。
如果在流程的後期發現了漏洞，即在應用程式提交審核之後，甚至會採取更嚴格的規則，因為實施熱修復可能會導致發布延遲。
雖然更新還沒有發布，但可能正在等待評審或已經獲得批准，要實施修復，我們將不得不拒絕構建並重新提交應用程式。因為這可能會導致延遲發布，我們會根據具體情況評估修復是否值得以及如何根據具體情況進行修復。
在獲得蘋果公司的批准後，新版本將向 1% 的用戶發布，確保沒有出現重大問題，並在幾天後推向整個用戶群。在這個階段，團隊使用一些關鍵指標來了解新版本的組件可能出現的問題。同樣，發布經理使用 Sentry 跟蹤更高級別的指標，如崩潰率和趨勢性問題。
英文原文：
https://www.infoq.com/news/2023/12/doordash-mobile-release-process/
洞見 re:Invent：生成式 AI 與雲共舞，成為構建者最好的時代來臨！
行業熱議：數據中台下一步是數據飛輪？
Mesos 時代徹底消亡：10 年創業掙扎、微軟谷歌收購未果，這家公司還是倒閉了
從滴滴的故障中我們能學到什麼