本文爲 Coding 用戶協作翻譯，轉載請註明來源。如果你對本文的翻譯有建議，歡迎提交 Pull Request 。
讓我們來聊聊部署
無論你何時對自己的代碼庫做出改動，總會伴隨着要破壞一些東西的風險。
沒有人喜歡宕機, 沒有人喜歡暴躁的用戶, 也沒有人喜歡生氣的經理，所以部署新代碼到生產環境變成頗具壓力的一個環節。
你完全沒必要對它有壓力，我將在這裏重複一遍又一遍這句話：
你的部署應該儘可能單調、直接、毫無壓力。
部署新功能到生產環境中應該像在 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% 的時間在處理基礎上。如果他們從開始時就是流水化的，每件事都會恰當地處理並且更爲迅速。
測試
測試是前期一個最簡單的地方。在一些淺顯的依賴處理中這不是一個必需的步驟，不過卻對其着有着巨大的影響。
這裏很多技巧取決於你的語言，平臺或者框架，不過普遍的建議是測試你的代碼 ，並提高測試速度。
我最喜歡引用 Ryan Tomayko 在 GitHub 的內部測試文檔裏寫的：
我們能讓好的測試變快卻不能讓快的測試變好。
所以以一個好的基礎開始：做個好的測試，別吝嗇這點，因爲它影響一切的方向。
一旦你開始有一個值得依靠的質量測試套件，儘管在開始時得花錢。如果你有任何形式的收入或者你們幕後團隊的資助，幾乎頭號你應該花錢的地方就是你應該運行測試的地方。如果你使用 Travis CI 或者 CircleCI ，如果你能運行並行編譯構建那麼就重複今天所做的。如果你需要在特定的硬件上運行，那就買巨大的服務器。
我見過一些公司通過遷移到更加快的測試套件上使其獲得了最重要的生產力優勢，而你也能賺到，因爲它影響迭代反饋週期，縮短依賴時間，增加開發者的幸福感並且使其成爲一種慣性。在問題解決方案上花錢吧：因爲服務器很便宜，但程序員卻不。
我在 Twitter上 做過一個非正式的投票 問我的 followers 他們的測試套件究竟跑得有多快。誠然，很難解釋那些微小服務，語言差異上居然有驚人數目的人從來沒有做過測試。不過在全棧和更快的單元測試者對決中，它表現的還是非常明顯。大多數人在 push 後至少要等待5分鐘才能看到構建狀態。
快究竟指多快呢？ 當我在 GitHub 時，測試一般在 2-3 分鐘內跑完。我們並沒有很多集成測試，所以允許以相對較快的速度測試，但是實際上你測試的越快，你就能越快的得到開發人員的循環反饋。
有許多的項目旨在幫助你並行化構建項目。在 Ruby 裏有 parallel_tests 和 test-queue 。比如你的測試沒有相互完全獨立，以不同的方式編寫測試是一個很好的方法，如果情況相反，你也應該好好處理它。
Feature Flags
這一切的另一個方面是開始看你的代碼並且把它轉化來支持多渠道部署代碼路徑。
重複一遍，我們的目標是你的部署應該儘可能單調，直接，無壓力。部署任何新代碼的自然壓力是代碼運行出你無法預見的問題，你最終影響到用戶的行爲（即他們經歷的停機時間和錯誤）。即使你有宇宙中最好的程序員，糟糕的代碼將最終被部署。不管這些壞代碼是影響 100% 的用戶或只是一個對你們非常重要的用戶。
用一個簡單的方法來處理，那就是 Feature Flag 。 Feature Flag 已經出現很久了，至少，技術上講，是自從 if 語句發明開始的，而我記得第一次真正聽到有公司的使用 Feature Flag 是 Flickr 在 2009 年的一篇文章。Flipping Out
這允許我們開啓我們正在開發的功能而不影響其他開發人員正在開發的功能。它也可以讓我們打開或關閉測試單獨的功能。
只有你可以看到，或只有你的團隊可以查看 flags，或所有員工都能看是兩件不同的事：你可以在現實世界使用真實的數據測試代碼，並確保一切工作正常；你還可以得到真正的關於該功能正式發佈時得到關於性能和風險的 benchmarks。
所有這一切的對你準備部署新的功能是大大有利的，你需要做的就是修改一行代碼爲 true ，然後每個人都看到了新的代碼。這使得通常嚇人的新版本部署變爲爲單調，直接，且無壓力。
可查驗的正確的部署
作爲一個額外的步驟，Feature Flag 提供了一個很好的方式來證明你的即將代碼部署不會對性能和可靠性產生不利影響。最近幾年一些新的工具能幫助你做到這個。
我在幾年前的演講文章 《Move Fast and Break Nothing》 中談過，它的主要內容是在生產環境運行 Feature Flag 的兩個代碼路徑中，並且只返回舊代碼的結果，觀察你引進的新代碼與你即將更換的新代碼的表現。一旦你有了這些數據，你可以確保你不會破壞任何事情。部署將變得單調，直接，無壓力。
GitHub 上一個叫做 Scientist 的開源 Ruby 庫能抽象的幫助你很多。這個庫已經這點上被移植到最受歡迎的語言上，所以如果你感興趣，它可能很值得你花時間去看一看。
另一種方法是灰度發佈。一旦你對要部署的代碼是準確無誤充滿信心，首先你仍然謹慎地僅公開到一小部分用戶來進行雙重檢查和三重檢查，直到沒有產生什麼破壞。破壞 5% 用戶的體驗比破壞 100% 用戶的體驗要好得多。
有大量旨在幫助你的庫，從 Ruby 中的 Rollout ， Java 中 Togglz ，到 JavaScript 中的 fflip ，和許多其他的。還有很多初創公司在爲這個問題提供解決方案，比如 LaunchDarkly 。
另外值得一提的是，這並不僅僅是 Web 的事情。本地應用也可以從中獲益良多。粗略看下 GroundControl 這個 iOS 中處理表現的庫就懂了。
在代碼構建上自我感覺良好？贊，我們現在來跳出這點，開始討論下部署。
用分支管理
很多圍繞部署的組織問題被部署者與其他人缺少溝通阻礙着。你需要每個人瞭解了你即將上線的代碼的方方面面，在做這個同時避免踩到她人的腳趾。
這裏有幾個可以幫到你的有趣的方式，它們都取決於部署的最簡單元：分支。
代碼分支
分支，我是指 Git，Mercurial 等版本控制系統的分支。先切出一個分支，在該分支上編程，然後推送代碼到你喜愛的代碼託管平臺（如 GitLab，Bitbucket，Coding 等）
你也應該使用 Pull Requests，Merge Request，或其他 code review 工具去評審寫好的代碼。部署環節必須要協作，代碼評審是非常重要的一部分。我們稍後會進一步說明這塊。
代碼評審
代碼評審這個話題太大，太複雜，且依你的團隊和風險狀況不同。我認爲這裏有幾個重要的問題需要所有的團隊去思考：
-
你的分支你負責。 我見過的成功型公司都有這個理念，即部署代碼失敗的最終負責人是寫這個代碼的人。他們不把部署失敗的責任歸結於部署上線的人然後就去起牀喫飯，當然這些人應該參與代碼評審，但最重要的是你要對你自己的代碼負責。如果它（編譯）失敗了，你自己去解決.......而不是你可憐的 ops 團隊。所以不要搞砸它。
-
儘早開始並經常性進行評審。 你不需要完成一個分支後再去請求評審。如果你可以發起一個關於預期代碼的評審請求，比如，花了 20 分鐘在這上面然後被通知說 “不，我們不用做這個了” 遠遠比之後花兩週時間寫這個代碼更好。
-
總是需要某人來評審代碼。 你可以依靠團隊來做這個，但有一雙專門負責評審的眼睛是非常有幫助的。對於結構化程度高的公司，你可能要明確指派人來負責代碼評審，並要求他們在代碼完前就開始 review。對於結構化程度較低的公司，你可以指派不用的團隊看看誰最可以幫到你。在光譜的兩端，你設定的期望是有人在猛衝前給你搭把手，或獨自部署代碼。
分支和部署節奏
這裏有個關於代碼評審的老段子。無論何時你開啓了一個關於 6 行代碼的評審請求，你總會得到很多同事關於這 6 行代碼的指指點點。但當你 push 了一個花了幾周時間的代碼分支，你常常會得到一個很快回復的：贊，我看行！
基本上，程序員常常都是一羣很討厭的懶蟲。
但你可以利用其作爲你的優勢，通過：使用盡快，較小的分支和 Pull Request。讓代碼小到可以很容易讓人隨時切入並進行評審。如果你寫了大型的分支，這需要別人花很長時間去 review，同時拖慢了整個開發的進度。
如何讓代碼更小？這時之前說的 feature flags 就派上用場了。當 2014 年我團隊的三個人重建 GitHub 的 Issues 時，我們向 Production 推送了大約上百數量的使用 Feature Flag 的小型 Pull Requests。我們部署了很多小單元（在其“完美”之前）。這讓代碼評審更簡單，同時讓部署更快，更早看到線上的產品狀況。
你需要快速並頻繁地部署。十人規模的團隊可以每天無憂地部署至少 7-15 個分支。重複一遍，diff 越小，部署就越單調，越直接，越無壓力。
部署分支
當你準備好部署你的新代碼，你應該總是在合併代碼前部署你的分支。注意"總是"。
查看整個代碼庫作爲事實的記錄。你的 master 分支（或你指定的任何的默認主分支）應該作爲你的生產環境的絕對鏡像。換句話說，你需要確保你的主分支是“沒問題的”，就是該分支沒有任何已知的問題。
分支是個大問題。如果你合併你的分支到 master 然後就部署 master 分支，你無法簡單地判斷代碼是否正常，“沒問題”分支是無需做任何噁心的代碼回滾操作的分支。
這不一定是火箭科學才需要的事情，但如果你的部署搞壞了網站，最後你就需要反思下了。你需要一個簡單的方法。
這就是爲什麼你的部署工具應該支持你部署分支是很重要的。一旦你確認你的性能沒有波動，沒有穩定性問題，功能可用性在預期內，你就可以 merge 它了。這麼做的原因不是爲了確保事情可行，而是防止事情不可行。當其出錯時，你的解決方案應該是單調，直接且無壓力的：重新部署 master 分支即可。就是這樣。你回到了“沒問題”的狀態。
自動部署
重要的是要對你的“已知狀態”有清晰的定義，最簡單的方法就是定一個簡單的不出錯的規則：
除非你正在測試一個分支，所有部署到生產環境的都始終由 master 分支體現。
我見過的最簡單的方法是保持在 master 分支設置自動部署。這是超簡單的規則組，它鼓勵大家向分支做出最無風險的提交。
這裏有很多工具平臺可用，如 Heroku 可以自動部署最新分支。CI 工具如 Travis CI （譯者注：國內有 flow.ci ）也可以幫你自動部署。或私有部署的 Heaven 和 hubot-deploy-tools （我們稍後會提到）也可以幫到你。
自動部署在你 merge 你工作的分支到 master 分支時也有幫助。你的工具應該可以選取一個新的修訂並重新再次部署網站。儘管軟件內容沒變（你在有效的部署同一套代碼），SHA-1 值變化了，這使生產環境的已知狀態變得更加明確（再次重申下，master 分支是已知狀態）。
藍綠部署
Martin Fowler 曾經在 2010 年的文章推崇過 藍綠部署（很值得一讀）。在其中，Fowler 談論到使用兩種理想的生產環境的理念，即他說的“藍”和“綠”。藍意味着在線的生產環境，綠代表空閒的生產環境。你可以部署到綠色集羣，確認一切正常運行後，通過無縫切換（如負載均衡）切換到藍色集羣。如此，生產環境收到了沒有風險的代碼。
自動部署的一個挑戰就是切換，將軟件從測試的最後環節檢出到生產環境。
這是一個非常強大的想法，而日益普及的虛擬化，容器技術和（可以很容易地扔掉，被遺忘的）自有環境使它變得更加強大。除了一個簡單的藍色/綠色的部署，你也可以讓生成產環境流動起來，因爲一切都是虛擬的。
這裏有很多解決方法，從災備恢復到在用戶看到它前附加時間測試關鍵功能，但我最喜歡的是附加功能使用代碼。
使用新代碼是在產品開發週期非常重要的。當然，很多問題應提前在代碼審查或通過自動測試找到了，但如果你正在嘗試做真正的產品，有時很難預測直到你已經長時間試過了真實的數據。這就是爲什麼藍綠部署比有一個簡單的臨時服務器更重要，其數據可能過時了或完全捏造。
更重要的是，如果你需要你的代碼部署到特定的環境中，你就可以在早期開始就引入不同利益相關者。不是每個人都有技術能力把你的代碼拉取到他們的計算機上，並在本地安裝你的代碼 - 而且這也是不應該的！比如，如果你能給你的會記部門展示你的新的上線情況的屏幕，在整個公司看到它之前，他們可以給你一些關於它的現實反饋，這可以幫你在早期找到很多的錯誤和問題。
Heroku Pipelines
不管你用不用 Heroku，看一下他們生態系統中的“Review Apps”理念：apps 直接從一個 Pull Request 進行部署，直接上線而不是截圖或大幅的關於“這就是它上線後的樣子”的描述。讓更多人儘早參與進來而不是你之後試圖用爛的產品說服他們。
控制部署流程
你看，當我在談一個創業公司的組織方式時，我是完全嬉皮自由雅痞的：我篤信開發者的自主性，用一種自下而上的方法去開發，注重人而不是管理。我認爲這會讓大家更快樂且讓產品更好。但在部署時，嗯哼，這是非常重要的，屬於 all-or-nothing 的需要做好的事情，所以我覺得這裏加入管控是合理的。
幸運的是，部署工具就是加入限制，從而把大家從壓力中解放出來，所以如果你做對了將大大獲益，而不是常人說的這將是阻礙。換句話說，你的流程應該促使事情搞定，而不是阻礙它。
審計跟蹤
我驚訝一些竟然不可以很快拿到審計日誌的創業公司。儘管可能會有一些聊天記錄可查，但這不應該是你需要時拿不出來的東西。
審計跟蹤的好處就是你預見到的：你可以找出是何時何地何人部署的。當你之後遇到問題時，你可以回滾到某一節點，這將節省不少時間。
很多服務都提供了這類的部署日誌。如 Amazon CodeDeploy 和 Dockbit，提供了廣義上的部署工具並提供了很好的追蹤工具。GitHub 傑出的部署 API （譯者注：Coding.net 也提供了 部署 API）也是很好的從 Pull Request 部署集成到你的外部系統的好辦法。
GitHub 的開發 API
如果你在專家模式，在你的部署和部署時間需要插入很多數據庫和服務，如 InfluxDB，Grafana，Librato 或 Graphite。可以在給定指標和部署層指標中對比是非常強大的：起初看到一個意外的指標增加或許讓你好奇，但當那是一次部署在發生時，你就不會感到意外了。
部署鎖定
如果你走到了在一個代碼庫中有很多人的這一步，你自然會遇到有很多人在某時都準備部署各自代碼的狀況。當然同時部署多個分支到生產環境是可行的，但我建議，當你走到這一步時，你需要些處理這種情況的工具。部署鎖定就是我們要了解的第一個東西。
部署鎖定基本是你已經預料到的東西：鎖定生產環境以便大家可以依次進行部署。這裏有很多方法可行，但最重要的是你要讓這 可見。
實現這一目標的最簡單辦法就是通過聊天。一個常見的方式可以是設置部署命令鎖定生產環境，比如：
/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 分鐘。宗旨就是：拉完屎趕緊走。
部署隊列
一旦你有很多部署要安排且你有很多人員準備部署，你顯然會有一些部署爭論。對於這一點，從你內心深處的英國紳士特色中選擇，形成一個部署隊列。
一個部署隊列有幾個部分：1）如果需要等待，把你的名字添加到末尾，2）允許有人插隊 （有些非常重要的部署需要立即執行，你需要允許這樣做）
部署隊列的唯一問題就是有太多人排隊部署了。GitHub 從過去一年至今都面臨這個問題；在週一人人都想部署他們的變更，部署列表看起來可以持續一個小時或更久。我不是特別提倡微服務，但我認爲部署隊列有一個好處就是你可以從雄偉的巨石中劈東西了。
權限
有很多方法可以限制使用部署權限的人。
兩步驗證是一個選項。最好你的僱員聊天帳號不會被公開，最好他們在他們電腦上有其他安全措施（全盤加密，強密碼等等），但是如果你要安心的話，最好要求他們開啓兩步驗證。
或許你已經有提供兩步驗證服務的聊天服務商，如 Campfire 和 Slack。（譯者注：Coding.net 也提供了 兩步驗證 ） 如果你需要在部署前進行兩步驗證，你可以在其流程中增加兩步驗證。
另一種可行的處理方法是，我稱權限外的調查員爲“騎獵槍”。我見過很多擁有正式或非正式的流程或工具去保證至少有一位高級開發人員參與每一步部署。這裏沒有理由不這麼做，比如，要求你的部署人員和高級開發人員（騎獵槍）去確認代碼可以部署。
欣賞並檢驗你的工作
一旦你部署完你的代碼，便是時候開始驗你是否真的做了你所想做的。
檢查你的 Playbook
無論是更新前端、後端或其他任何代碼，每次部署都必須符合同一個策略方針。你必須查看網站是否還正常運行着，是否性能突然變得更糟糕，是否產生更多誤碼率，亦或者有更多反饋的問題等等。所以說精簡那個策略方針將對你非常有利。
對於上述的不同方面，如果多個信息來源，試着比如在最終確認部署的時候給每個儀表盤中加一個鏈接。這樣每次都能提醒大家觀察並驗證這些變更是否對度量指數產生了負面影響。
理想狀態下，應從一個來源裏獲取信息。這樣更容易指引，比如一個新員工在第一次部署的時候該觀察重要的度量指數。比如 Printerest 的 Teletraan 在一個界面裏就包含了所有的信息。
度量指數
有很多可以收集的度量指數將有助於你判斷剛剛部署得是否成功。
當然最顯著的是誤碼率。如果它突然急速上升，意味着你可能得重新部署 master 分支並且修復這些問題。這些過程可以自動化實現，甚至可以設定一個閾值，如誤碼率超了就自動重新部署。如果你確定 master 是一個對你來說熟知並且可以回滾的分支，那麼自動回滾將變得更容易，一旦你部署後就觸發大量異常則自動回滾部署。
部署本身也是個很有意思的度量，值得放在手上。一個很好的例子就是縱覽過去一年的部署情況，可以幫助你瞭解部署的節奏是在放大，或者讓你瞭解它慢下來的原因。你可以進一步收集是誰在部署，誰導致了錯碼，並開發一種能夠檢測團隊開發者是否可靠的方法。
部署後的清理
最後一步需要做的家務活就是清理。
Feature Toggles 是最糟糕的技術債之一 對這進行了討論，雖然這個標題有點激進。如果你正在構建一些有 feature flags 以及人員發展的項目，你將面臨長期使你代碼庫的變得更復雜化的風險：
用管道與腳手架邏輯支持代碼分支是一種令人討厭的技術債務，因爲自此以後每個功能開關都要引入。Feature flags 使得代碼更脆弱，很難測試、理解、維護、支持，也更不安全。
你不需要部署完就立刻清理；如果你有一個新功能或者 bug 修復的需求，你應該花時間在監測系統指標，而不是立刻刪除代碼，儘管部署後不久你還是得這樣做。如果你有一個重大版本發佈， 你可以在一天或一星期後回顧並刪除那些已經不用的代碼。我喜歡做的一件事就是準備兩個 pull request：一個是切換 Feature flags （比如，開放該功能給所有人），另一個是清除所有的你引入的冗餘代碼。當我確保我沒破壞任何事情並且看上去不錯的話，我就可以合併第二個 pull request 而不需再更多的考慮或開發。
你還需要給自己慶祝一番：因爲這個終極信號意味着你們已經成功地完成了這個項目。所有人都會喜歡看到 diff 幾乎都變紅的狀態，刪除代碼的確是件很開心的事情。
刪除分支
當你完成任務後，你同樣可以刪除分支，這肯定是不會錯的。但如果你用的是 GitHub 的 pull request，你通常可以保留刪除的分支，這樣相當於從分支列表中刪除了該分支，但其實不會有任何的數據丟失。這個過程同樣也可以自動完成：定期執行一個腳本，檢查你那些陳舊的已合併到 master 的分支並且刪除它們。（譯者注：Coding.net 的 Merge Request 也提供了 merge 後自動刪除分支功能）
整個球賽
我只對兩種事情感到情緒激動：一個是一張動人的照片：山頂上一隻金毛尋回犬倚着它最好的朋友，面朝大海，看夕陽西下；還有就是部署工作流。我如此關心這件事是因爲它是整個比賽最關鍵的一部分，在一天結束的時候，我只關心兩件事情：同事的感覺是怎麼樣的，我工作的產品是怎麼樣的。對我來說其他一切皆源於這兩方面。
部署可以造成壓力和挫折，尤其當你的公司開發節奏是遲緩的，也可以減緩和阻止你添加新功能、爲用戶修復 BUG。
我認爲思考這些是值得的，優化自己的工作流也是值得的。花一些時間讓自己的部署變得儘可能單調、直接、無壓力，是會得到回報的。