為何你的系統不能穩定執行？

圖源來自Pexels

---

什麼才是軟體釋出的“正確”方法？

精確的估算編碼，詳盡的規格定義？還是通過 A/B 測試的UI設計？亦或是考慮周詳的技術文件？當你近乎狂熱地嘗試將這些實踐經驗複製到其他產品上時，你的魔法往往會失靈。

那麼，如果設計不夠，模式不夠，我們應該如何應對不可避免的災難？

本期直播，我們邀請到了ThoughtWorks首席諮詢師，《釋出！設計與部署穩定的分散式系統（第2版）》一書譯者伍斌，3月26日（本週四）晚20:00，在圖靈社群技術社群，以“《釋出！》精讀：如何面對不可避免的災難？”為主題，詳解從需求到釋出整個過程以及相關工具，開發和運維如何高效工作，來應對不可避免的災難？

---

參與形式☟

視訊直播

掃碼新增圖靈小姐姐微信（turingbook），回覆關鍵字“釋出”，進入直播群，獲得直播地址。

預習資料選讀☟

1.什麼是DevOps？DevOps是軟體研發的洗碗機

Brain Kelly通過洗碗這件事，通俗地解釋了兩個重要概念：Donald Reinertsen提出的U曲線和DevOps。

https://mp.weixin.qq.com/s/gs_DipP8ZPejKECBNKALew

2.DevOps從入門到進階，必讀的圖靈經典讀物！

《鳳凰專案》

• 一本引發全球IT從業者強烈共鳴的小說，一個IT運維的傳奇故事。

全書講述了一名IT經理Bill臨危受命，在未來董事的幫助和自己The Three Ways理念的支撐下，挽救工期和預算都大大超期的鳳凰專案，最終挽救一傢俱有悠久歷史的汽車配件製造商的故事。

《DevOps入門與實踐》

• 手把手教你在開發現場引入DevOps的具體流程

首先介紹如何提高個人開發效率和自動化程度，然後過渡到在團隊內開展DevOps的方法，最後介紹引入DevOps的最佳實踐。由淺入深，條理清楚，方便讀者快速上手。

《持續交付：釋出可靠軟體的系統方法》

• Jolt大獎獲獎圖書，推薦給所有嚴肅對待自己工作的軟體開發者

本書講述如何實現更快、更可靠、低成本的自動化軟體交付，描述瞭如何通過增加反饋，並改進開發人員、測試人員、運維人員和專案經理之間的協作來達到這個目標。

《釋出！設計與部署穩定的分散式系統（第2版）》

• 第18屆Jolt生產效率獎，助你在釋出軟體後能睡個好覺！

作者根據自己的親身經歷和某些大型企業的案例，講述瞭如何建立高穩定性的軟體系統，分析了設計和實現中導致系統出現問題的原因。

3.寫給小團隊的軟體釋出管理

在此篇文章中，專門從開發人員的視角，提供關於如何正規化釋出流程的一些技巧。

https://my.oschina.net/dogstar/blog/656067?nocache=1546063089295

最後，關於軟體部署，想推薦GitHub的元老級工程師Zach Holman寫的HOW TO DEPLOY SOFTWARE ？這篇文章來源於作者本人和其他團隊關於部署難題的一些談話。

HOW TO DEPLOY SOFTWARE?

作者 Zach Holman

本文為 Coding 使用者協作翻譯，轉載請註明來源。如果你對本文的翻譯有建議，歡迎提交 Pull Request 。

https://blog.coding.net/blog/deploying-software

一、讓我們來聊聊部署

無論你何時對自己的程式碼庫做出改動，總會伴隨著要破壞一些東西的風險。

沒有人喜歡當機, 沒有人喜歡暴躁的使用者, 也沒有人喜歡生氣的經理，所以部署新程式碼到生產環境變成頗具壓力的一個環節。

你完全沒必要對它有壓力，我將在這裡重複一遍又一遍這句話：

• 你的部署應該儘可能單調、直接、毫無壓力。

部署新功能到生產環境中應該像在 Hacker News 開始一場關於 用 spaces 還是 tabs 的口水戰一樣簡單。它應該足夠簡單到讓新員工理解，它應該為防止錯誤而生，它應該在第一個終端使用者看到新程式碼前被很好地測試過。

這是一篇高層次談論部署的文章，包含了：協作，安全和速度等，在底層方面也講了很多，但這些都是很難跨語言進行概括，並且說實話，比起在高層次技術方面有很多更密切的問題要去解決，我更喜歡談論團隊如何協同工作，而部署是與其他人協作最關鍵的一部分。我認為你值得花時間並不時地來評估你團隊的狀況。

有很多來自我在 GitHub 任職 5 年的經驗，和去年我給大大小小科技公司提供建議和諮詢的經驗。這裡，我特別推薦一個初創公司Dockbit ，其產品是旨在正視部署中的合作。這篇文章來源於許多關於我和他們團隊的談話，我認為寫下來許多部署難題中的不同部分會大有益處的。

我很感激一些來自不同公司的朋友給予這篇文章的校對和幫忙，並提供各自在部署上不同的觀點：Corey Donohoe (Heroku) ， Jesse Toth (GitHub) ， Aman Gupta (GitHub) ， 和 Paul Betts (Slack) 。我不斷的發現不同的公司可能採取不同路徑，但一般都集中在合作，風險和謹慎這種基礎方面，我覺得這個東西在這裡是普遍適用的。

不管怎麼說，對於這個漫長的導語我感到很抱歉，但無論如何這篇文章將是很長的，請盡力讀完吧，lol。

二、目錄

• 目標

難道部署不是一個已經解決的問題嗎?

• 準備

開始為部署做準備：測試，feature flags 和你的開發協作方式。

• 分支

為你的程式碼設定建立分支是部署最基本的部分。在部署新程式碼時你能把其中導致任何可能意外後果的部分分離出來。開始思考部署分支，自動部署 master 分支，藍／綠部署。

• 控制

部署的核心。你如何才能控制被髮布的程式碼。處理在部署和合並中不同的許可權結構，為你的部署建立一套審計跟蹤，通過部署鎖定和部署佇列讓一切有序。

• 監視

Cool，你的程式碼已經在生產環境了。現在你可以關心的你的部署在不同方面的監視指標，並且最終做出是否要為你的改動回滾程式碼的決定。

• 結論

"我們學到了什麼， Palmer ?"
"先生我不知道。"
"我 TM 也不知道。我猜我們學到的就是，不要再這麼做了。"
"是的，先生。"

• How to Deploy Software was originally published on March 1, 2016.

三、難道部署不是一個已經解決的問題嗎?

如果你說的是拉取程式碼並將它們傳送到不同的伺服器上，那麼事情已經解決得很漂亮並且這些事情相當無聊。你已經獲得了 Ruby 中的 Capistrano（一種遠端伺服器自動化工具）， Python 中的 Fabric(Python 的一個類庫以及命令列工具)，Node 中的 Shipit （Javascript 寫的一個通用自動化和釋出工具），以及所有的亞馬遜雲服務，甚至是 FTP 也貌似會存在好幾個世紀，因此工具現在真的不是問題。

如果我們此時有了相當不錯的工具，為什麼部署會出錯呢？為什麼人們總是釋出 bug 呢？為什麼總是存在當機的情況？我們可都是寫完美程式碼的完美程式設計師啊，這真是見鬼了！

很明顯，事情總是始料未及地發生，所以我認為部署應該是中小型公司應關注的有趣領域，其他領域沒有如此好的投入產出比。你可以做好儘早處理和應對問題的工作流程嗎？你可以使用不同的工具來更簡單地進行協助部署嗎？

• 這不是工具問題，這是處理的問題。

我對很多很多創業公司講，過去的幾年，還沒有一個從組織的角度看上去“好的”部署工作流。 你無需負責部署的專人，無需特定一個部署日期，無需在每次部署時動用所有人手。你只需要採取一些聰明的辦法。

四、在一個好的基礎上開始

在跑之前你必須走起來。我認為初創公司有一個很時髦的方面就是它們都用著最酷並且最新的部署工具，但是當你切進去觀察他們的處理時，會發現他們花了 80% 的時間在處理基礎上。如果他們從開始時就是流水化的，每件事都會恰當地處理並且更為迅速。

1.測試

測試是前期一個最簡單的地方。在一些淺顯的依賴處理中這不是一個必需的步驟，不過卻對其著有著巨大的影響。

這裡很多技巧取決於你的語言，平臺或者框架，不過普遍的建議是測試你的程式碼 ，並提高測試速度。 我最喜歡引用 Ryan Tomayko 在 GitHub 的內部測試文件裡寫的：

• 我們能讓好的測試變快卻不能讓快的測試變好。

所以以一個好的基礎開始：做個好的測試，別吝嗇這點，因為它影響一切的方向。

一旦你開始有一個值得依靠的質量測試套件，儘管在開始時得花錢。如果你有任何形式的收入或者你們幕後團隊的資助，幾乎頭號你應該花錢的地方就是你應該執行測試的地方。如果你使用 Travis CI 或者 CircleCI ，如果你能執行並行編譯構建那麼就重複今天所做的。如果你需要在特定的硬體上執行，那就買巨大的伺服器。

我見過一些公司通過遷移到更加快的測試套件上使其獲得了最重要的生產力優勢，而你也能賺到，因為它影響迭代反饋週期，縮短依賴時間，增加開發者的幸福感並且使其成為一種慣性。在問題解決方案上花錢吧：因為伺服器很便宜，但程式設計師卻不。

我在 Twitter上 做過一個非正式的投票，問我的 followers 他們的測試套件究竟跑得有多快。誠然，很難解釋那些微小服務，語言差異上居然有驚人數目的人從來沒有做過測試。不過在全棧和更快的單元測試者對決中，它表現得還是非常明顯。大多數人在 push 後至少要等待5分鐘才能看到構建狀態。

快究竟指多快呢？當我在 GitHub 時，測試一般在 2-3 分鐘內跑完。我們並沒有很多整合測試，所以允許以相對較快的速度測試。但是實際上，你測試的越快，你就能越快的得到開發人員的迴圈反饋。

有許多的專案旨在幫助你並行化構建專案。在 Ruby 裡有 parallel_tests 和 test-queue 。比如你的測試沒有相互完全獨立，以不同的方式編寫測試是一個很好的方法，如果情況相反，你也應該好好處理它。

2.Feature Flags

這一切的另一個方面是開始看你的程式碼並且把它轉化來支援多渠道部署程式碼路徑。

重複一遍，我們的目標是你的部署應該儘可能單調，直接，無壓力。部署任何新程式碼的自然壓力是程式碼執行出你無法預見的問題，你最終影響到使用者的行為（即他們經歷的停機時間和錯誤）。即使你有宇宙中最好的程式設計師，糟糕的程式碼將最終被部署。不管這些壞程式碼是影響 100% 的使用者或只是一個對你們非常重要的使用者。

用一個簡單的方法來處理，那就是 Feature Flag 。Feature Flag 已經出現很久了，至少，技術上講，是自從 if 語句發明開始的，而我記得第一次真正聽到有公司使用 Feature Flag 是 Flickr 在 2009 年的一篇文章——Flipping Out。

• 這允許我們開啟我們正在開發的功能而不影響其他開發人員正在開發的功能。它也可以讓我們開啟或關閉測試單獨的功能。

只有你可以看到，或只有你的團隊可以檢視 flags，或所有員工都能看是兩件不同的事：你可以在現實世界使用真實的資料測試程式碼，並確保一切工作正常；你還可以得到真正的關於該功能正式釋出時得到關於效能和風險的 benchmarks。

所有這一切的對你準備部署新的功能是大大有利的，你需要做的就是修改一行程式碼為 true ，然後每個人都看到了新的程式碼。這使得通常嚇人的新版本部署變得單調，直接，且無壓力。

3.可查驗的正確的部署

作為一個額外的步驟，Feature Flag 提供了一個很好的方式來證明你即將部署得程式碼不會對效能和可靠性產生不利影響。最近幾年一些新的工具頁能幫助你做到這個。

我在幾年前的演講文章 Move Fast and Break Nothing 中談過，它的主要內容是在生產環境執行 Feature Flag 的兩個程式碼路徑中，並且只返回舊程式碼的結果，觀察你引進的新程式碼與你即將更換的新程式碼的表現。一旦你有了這些資料，你可以確保你不會破壞任何事情。部署將變得單調，直接，無壓力。

GitHub 上一個叫做 Scientist 的開源 Ruby 庫能抽象的幫助你很多。這個庫已經被移植到最受歡迎的語言上，所以如果你感興趣，它可能很值得你花時間去看一看。

另一種方法是灰度釋出。一旦你對要部署的程式碼是準確無誤且充滿信心，首先你得仍然謹慎地僅公開到一小部分使用者來進行雙重檢查和三重檢查，直到沒有產生什麼破壞。破壞 5% 使用者的體驗比破壞 100% 使用者的體驗要好得多。

這裡大量能幫助你的庫，從 Ruby 中的 Rollout ， Java 中 Togglz ，到 JavaScript 中的 fflip ，以及和許多其他的庫等。還有很多初創公司在為這個問題提供解決方案，比如 LaunchDarkly 。

另外值得一提的是，這並不僅僅是 Web 的事情。本地應用也可以從中獲益良多。粗略看下 GroundControl 這個 iOS 中處理表現的庫就懂了。

在程式碼構建上自我感覺良好？贊，我們現在來跳出這點，開始討論下部署。

五、用分支管理

很多圍繞部署的組織問題被部署者與其他人缺少溝通阻礙著。你需要每個人瞭解你即將上線的程式碼的方方面面，在做這個同時避免踩到他人的腳趾。

這裡有幾個可以幫到你的有趣的方式，它們都取決於部署的最簡單元：分支。

1.程式碼分支

分支，我是指 Git，Mercurial 等版本控制系統的分支。先切出一個分支，在該分支上程式設計，然後推送程式碼到你喜愛的程式碼託管平臺（如 GitLab，Bitbucket，Coding 等）。

你也應該使用 Pull Requests，Merge Request，或其他 code review 工具去評審寫好的程式碼。部署環節必須要協作，程式碼評審是非常重要的一部分。我們稍後會進一步說明這塊。

2.程式碼評審

程式碼評審這個話題太大，太複雜，且根據你的團隊和風險狀況不同，我認為這裡有幾個重要的問題需要所有的團隊去思考：

• 你的分支你負責。 我見過的成功型公司都有這個理念，即部署程式碼失敗的最終負責人是寫這個程式碼的人。他們不把部署失敗的責任歸結於部署上線的人，當然這些人應該參與程式碼評審，但最重要的是你要對你自己的程式碼負責。如果它（編譯）失敗了，你自己去解決.......而不是你可憐的 ops 團隊。所以不要搞砸它。

• 儘早開始並經常性進行評審。 你不需要完成一個分支後再去請求評審。如果你可以發起一個關於預期程式碼的評審請求，比如，花了 20 分鐘在這上面然後被通知說 “不，我們不用做這個了” 遠遠比之後花兩週時間寫這個程式碼更好。

• 總是需要某人來評審程式碼。 你可以依靠團隊來做這個，但有一雙專門負責評審的眼睛是非常有幫助的。對於結構化程度高的公司，你可能要明確指派人來負責程式碼評審，並要求他們在程式碼完成前就開始 review。對於結構化程度較低的公司，你可以指派不用的團隊看看誰最可以幫到你。在光譜的兩端，你設定的期望是有人在猛衝前給你搭把手，或獨自部署程式碼。

3.分支和部署節奏

有個關於程式碼評審的老段子：無論何時你發起了一個關於 6 行程式碼的評審請求，你總會得到很多同事關於這 6 行程式碼的指指點點。但當你 push 了一個花了幾周時間的程式碼分支，你常常會得到一個很快回復的：LGTM!（Looks Good To Me）。

基本上，程式設計師常常都是一群很討厭的懶蟲。

但你可以利用其作為你的優勢，通過使用盡快，較小的分支和 Pull Request。讓程式碼小到可以很容易讓人隨時切入並進行評審。如果你寫了大型的分支，這需要別人花很長時間去 review，同時拖慢了整個開發的進度。

如何讓程式碼更小？這時之前說的 feature flags 就派上用場了。當 2014 年我團隊的三個人重建 GitHub 的 Issues 時，我們向 Production 推送了大約上百數量的使用 Feature Flag 的小型 Pull Requests。我們部署了很多小單元（在其“完美”之前）。這讓程式碼評審更簡單，同時讓部署更快，更早看到線上的產品狀況。

你需要快速並頻繁地部署。十人規模的團隊可以每天無憂地部署至少 7-15 個分支。重複一遍，diff 越小，部署就越單調，越直接，越無壓力。

4.部署分支

當你準備好部署你的新程式碼，你應該總是在合併程式碼前部署你的分支。注意"總是"。

檢視整個程式碼庫作為事實的記錄。你的 master 分支（或你指定的任何的預設主分支）應該作為你的生產環境的絕對映象。換句話說，你需要確保你的主分支是“沒問題的”，就是該分支沒有任何已知的問題。

分支是個大問題。如果你合併你的分支到 master 然後就部署 master 分支，你無法簡單地判斷程式碼是否正常，“沒問題”分支是無需做任何噁心的程式碼回滾操作的分支。
這不一定是火箭科學才需要的事情，但如果你的部署搞壞了網站，最後你就需要反思下了。你需要一個簡單的方法。

這就是為什麼你的部署工具應該支援你部署分支是很重要的。一旦你確認你的效能沒有波動，沒有穩定性問題，功能可用性在預期內，你就可以 merge 它了。這麼做的原因不是為了確保事情可行，而是防止事情不可行。當其出錯時，你的解決方案應該是單調，直接且無壓力的：重新部署 master 分支即可。就是這樣。你回到了“沒問題”的狀態。

5.自動部署

重要的是要對你的“已知狀態”有清晰的定義，最簡單的方法就是制定一個簡單的不出錯的規則：

• 除非你正在測試一個分支，所有部署到生產環境的都始終由 master 分支體現。
  我見過的最簡單的方法是保持在 master 分支設定自動部署。這是超簡單的規則組，它鼓勵大家向分支做出最無風險的提交。

這裡有很多工具平臺可用，如 Heroku 可以自動部署最新分支。CI 工具如 Travis CI （譯者注：國內有 flow.ci ）也可以幫你自動部署。或私有部署的 Heaven 和 hubot-deploy-tools （我們稍後會提到）也可以幫到你。

自動部署在你 merge 你工作的分支到 master 分支時也有幫助。你的工具應該可以選取一個新的修訂並重新再次部署網站。儘管軟體內容沒變（你在有效的部署同一套程式碼），SHA-1 值變化了，這使生產環境的已知狀態變得更加明確（再次重申下，master 分支是已知狀態）。

6.藍綠部署

Martin Fowler 曾經在 2010 年的文章推崇過藍綠部署（很值得一讀）。在其中，Fowler 談論到使用兩種理想的生產環境的理念，即他說的“藍”和“綠”。藍意味著線上的生產環境，綠代表空閒的生產環境。你可以部署到綠色叢集，確認一切正常執行後，通過無縫切換（如負載均衡）切換到藍色叢集。如此，生產環境收到了沒有風險的程式碼。

• 自動部署的一個挑戰就是切換，將軟體從測試的最後環節檢出到生產環境。

這是一個非常強大的想法，而日益普及的虛擬化，容器技術和（可以很容易地扔掉，被遺忘的）自有環境使它變得更加強大。除了一個簡單的藍色/綠色的部署，你也可以讓生成產環境流動起來，因為一切都是虛擬的。

這裡有很多解決方法，從災備恢復到在使用者看到它前附加時間測試關鍵功能，但我最喜歡的是附加功能使用程式碼。

使用新程式碼是在產品開發週期非常重要的。當然，很多問題應提前在程式碼審查或通過自動測試找到了，但如果你正在嘗試做真正的產品，有時很難預測直到你已經長時間試過了真實的資料。這就是為什麼藍綠部署比有一個簡單的臨時伺服器更重要，其資料可能過時了或完全捏造。

更重要的是，如果你需要你的程式碼部署到特定的環境中，你就可以在早期開始就引入不同利益相關者。不是每個人都有技術能力把你的程式碼拉取到他們的計算機上，並在本地安裝你的程式碼——而且這也是不應該的！比如，如果你能給你的財務部門展示你的新的上線情況的螢幕，在整個公司看到它之前，他們可以給你一些關於它的現實反饋，這可以幫你在早期找到很多的錯誤和問題。

7.Heroku Pipelines

不管你用不用 Heroku，看一下他們生態系統中的“Review Apps”理念：apps 直接從一個 Pull Request 進行部署，直接上線而不是截圖或大幅的關於“這就是它上線後的樣子”的描述。讓更多人儘早參與進來而不是你之後試圖用爛的產品說服他們。

六、控制部署流程

你看，當我在談一個創業公司的組織方式時，我是完全嬉皮自由雅痞的：我篤信開發者的自主性，用一種自下而上的方法去開發，注重人而不是管理。我認為這會讓大家更快樂且讓產品更好。但在部署時，這是非常重要的，屬於 all-or-nothing 的需要做好的事情，所以我覺得這裡加入管控是合理的。

幸運的是，部署工具就是加入限制，從而把大家從壓力中解放出來，所以如果你做對了將大大獲益，而不是常人說的這將是阻礙。換句話說，你的流程應該促使事情搞定，而不是阻礙它。

1.審計跟蹤

我驚訝一些竟然不可以很快拿到審計日誌的創業公司。儘管可能會有一些聊天記錄可查，但這不應該是你需要時拿不出來的東西。

審計跟蹤的好處就是你預見到的：你可以找出是何時何地何人部署的。當你之後遇到問題時，你可以回滾到某一節點，這將節省不少時間。

很多服務都提供了這類的部署日誌。如 Amazon CodeDeploy 和 Dockbit，提供了廣義上的部署工具並提供了很好的追蹤工具。GitHub 傑出的部署 API （譯者注：Coding.net 也提供了部署 API）也是很好的從 Pull Request 部署整合到你的外部系統的好辦法。

2.GitHub 的開發 API

如果你在專家模式，在你的部署和部署時間需要插入很多資料庫和服務，如 InfluxDB，Grafana，Librato 或 Graphite。可以在給定指標和部署層指標中對比是非常強大的：起初看到一個意外的指標增加或許讓你好奇，但當那是一次部署在發生時，你就不會感到意外了。

3.部署鎖定

如果你走到了在一個程式碼庫中有很多人的這一步，你自然會遇到有很多人在同一時刻都準備部署各自程式碼的狀況。當然同時部署多個分支到生產環境是可行的，但我建議，當你走到這一步時，你需要些處理這種情況的工具。部署鎖定就是我們要了解的第一個東西。

部署鎖定基本是你已經預料到的東西：鎖定生產環境以便大家可以依次進行部署。這裡有很多方法可行，但最重要的是你要讓這可見。

實現這一目標的最簡單辦法就是通過聊天。一個常見的方式可以是設定部署命令鎖定生產環境，比如：

/deploy <app>/<branch> to <environment>

i.e.,

/deploy api/new-permissions to production

這使大家都明白你在部署什麼。我見過一些使用 Slack 的公司在 Slack 的部署聊天室裡說：我在部署……！我覺得這是沒有必要的，這隻會分散你同事的注意力。這裡只要把資訊扔進聊天室就夠了。如果你之後忘了做也可以新增一條額外命令讓系統返回目前生產環境的狀態。

這裡有很多簡單方法可以把這套工作流插入你的聊天室。Dockbit 有一個 Slack 整合。也有一個開源解決方案叫作 SlashDeploy 可以整合 GitHub 和 Slack。（譯者注：國內有 bearychat.com 提供了類似服務）

我還見過一些特製的關於這一步的網頁版工具。Slack 有個自定義的內部 App 提供了視覺化的部署。Pinterest 有一個開源的基於網頁的部署系統。你可以將鎖定的理念延伸到其他方面，這取決於如何使你的團隊最高效工作。

一旦部署分支被 merge 到 master 分支，生產環境應該自動解鎖以便下一個人進行操作。

這裡也有一定的鎖定禮儀。你當然不希望大家等待一個粗心的程式設計師忘記了解鎖生產環境。自動解鎖工具就派上用場了，比如，你也可以設定定時提醒部署人員其生產環境是否被鎖定超過了 10 分鐘。宗旨就是：拉完屎趕緊走。

4.部署佇列

一旦你有很多部署要安排且你有很多人員準備部署，你顯然會有一些部署爭論。對於這一點，從你內心深處的英國紳士特色中選擇，形成一個部署佇列。

一個部署佇列有幾個部分：1）如果需要等待，把你的名字新增到末尾；2）允許有人插隊 （有些非常重要的部署需要立即執行，你需要允許這樣做）。

部署佇列的唯一問題就是有太多人排隊部署了。GitHub 從過去一年至今都面臨這個問題。在週一人人都想部署他們的變更，部署列表看起來可以持續一個小時或更久。我不是特別提倡微服務，但我認為部署佇列有一個好處就是你可以從雄偉的巨石中劈東西了。

5.許可權

有很多方法可以限制使用部署許可權的人。

兩步驗證是一個選項。最好你的僱員聊天帳號不會被公開，最好他們在他們電腦上有其他安全措施（全盤加密，強密碼等等），但是如果你要安心的話，最好要求他們開啟兩步驗證。

或許你已經有提供兩步驗證服務的聊天服務商，如 Campfire 和 Slack。（譯者注：Coding.net 也提供了 兩步驗證 ） 如果你需要在部署前進行兩步驗證，你可以在其流程中增加兩步驗證。

另一種可行的處理方法是，我稱許可權外的調查員為“騎獵槍”。我見過很多擁有正式或非正式的流程或工具去保證至少有一位高階開發人員參與每一步部署。這裡沒有理由不這麼做，比如，要求你的部署人員和高階開發人員（騎獵槍）去確認程式碼可以部署。

七、欣賞並檢驗你的工作

一旦你部署完你的程式碼，就可以驗證您剛才所做的工作是否確實按照計劃執行。

1.檢查你的 Playbook

無論是更新前端、後端或其他任何更改，每次部署都必須符合同一個策略方針。你必須檢視網站是否還正常執行著，是否效能突然變得更糟糕，是否產生更多誤位元速率，亦或是有新的問題出現等。所以說簡化這個策略方針將對你是非常有利的。

對於上述的不同方面，如果多個資訊來源，試著比如在最終確認部署的時候給每個儀表盤中加一個連結。這樣每次都能提醒大家觀察並驗證這些變更是否對度量指數產生了負面影響。

理想狀態下，應從一個來源裡獲取資訊。這樣更容易指引，比如一個新員工在第一次部署的時候該觀察重要的度量指數。比如 Printerest 的 Teletraan 在一個介面裡就包含了所有的資訊。

2.度量指數

有很多可以收集的度量指數將有助於你判斷剛剛部署得是否成功。

當然最顯著的是誤位元速率。如果它突然急速上升，意味著你可能得重新部署 master 分支並且修復這些問題。這些過程可以自動化實現，甚至可以設定一個閾值，如誤位元速率超了就自動重新部署。如果你確定 master 是一個對你來說熟知並且可以回滾的分支，那麼自動回滾將變得更容易，一旦你部署後觸發大量異常則自動回滾部署。

部署本身也是個很有意思的度量。一個很好的例子，縱覽過去一年的部署情況，可以幫助你瞭解部署的節奏是在放大，或者讓你可以瞭解它慢下來的原因，同時你可以進一步收集是誰在部署，誰導致了錯碼，並開發一種能夠檢測團隊開發者是否可靠的方法。

3.部署後的清理

最後一步需要做的家務活就是清理。

Feature Toggles 是最糟糕的技術債之一 這進行了討論，雖然這個標題有點激進。如果你正在構建一些有 Feature flags 以及人員發展的專案，你將面臨長期使你的程式碼庫變得更復雜化的風險：

• 用管道與腳手架邏輯支援程式碼分支是一種令人討厭的技術債務，因為自此以後每個功能開關都要引入。Feature flags 使得程式碼更脆弱，很難測試、理解、維護、支援，也更不安全。

你不需要部署完就立刻清理。如果你有一個新功能或者 bug 修復的需求，你應該花時間在監測系統指標，而不是立刻刪除程式碼，儘管部署後不久你還是得這樣做。如果你有一個重大版本釋出， 你可以在一天或一星期後回顧並刪除那些已經不用的程式碼。我喜歡做的一件事就是準備兩個 pull request：一個是切換 Feature flags （比如，開放該功能給所有人），另一個是清除所有的你引入的冗餘程式碼。當我確保我沒破壞任何事情並且看上去不錯的話，我就可以合併第二個 pull request 而不需再更多的考慮或開發。

八、整個球賽

我只對兩種事情感到情緒激動：一個是一張動人的照片：山頂上一隻金毛尋回犬倚著它最好的朋友，面朝大海，看夕陽西下，還有就是部署工作流。我如此關心這件事是因為它是整個比賽最關鍵的一部分，在一天結束的時候，我只關心兩件事情：同事的感覺是怎麼樣的，我工作的產品是怎麼樣的。對我來說其他一切皆源於這兩方面。

部署可以造成壓力和挫折，尤其當你的公司開發節奏是遲緩的，也可以減緩和阻止你新增新功能、為使用者修復 BUG。

我認為思考這些是值得的，優化自己的工作流也是值得的。花一些時間讓自己的部署變得儘可能單調、直接、無壓力，是會得到回報的。