如何部署軟件 - 讓你團隊的部署像地獄同樣無聊且毫無壓力

時間 2019-11-10

標籤如何部署軟件讓你團隊地獄同樣聊且毫無壓力简体版

原文原文鏈接

讓咱們來聊聊部署

不管你什麼時候對本身的代碼庫作出改動，總會伴隨着要破壞一些東西的風險。html

沒有人喜歡宕機，沒有人喜歡暴躁的用戶，也沒有人喜歡生氣的經理，因此部署新代碼到生產環境變成頗具壓力的一個環節。前端

你徹底不必對它有壓力，我將在這裏重複一遍又一遍這句話：git

你的部署應該儘量單調、直接、毫無壓力。程序員

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

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

有不少來自我在 GitHub 任職 5 年的經驗，和去年我與大大小小科技公司提供建議和諮詢的經驗，對在提升他們的部署工做流程的重點上（已經從「很是可敬」到概括於「我以爲這服務器已經着火了」）。我特別推薦一個初創公司，Dockbit ，其產品是旨在正視部署中的合做，等等。這篇文章來源於許多關於我和它們團隊的談話，我認爲寫下來許多部署難題中的不一樣部分會大有益處的。編程

我很感激一些來自不一樣公司的朋友給予這篇文章的校隊和幫忙，並提供各自在部署上不一樣的觀點： Corey Donohoe (Heroku) ，Jesse Toth (GitHub) ，Aman Gupta (GitHub) ，和 Paul Betts (Slack) 。我不斷的發現不一樣的公司可能採起頗有趣的不一樣路徑，但通常都集中在合做，風險和謹慎這種基礎方面，我以爲有東西在這裏具備廣泛性。後端

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

目標難道部署不是一個已經解決的問題嗎?安全
準備開始爲部署作準備：測試，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 後自動刪除分支功能）