|
作者 Zach Holman 本文為 Coding 用戶協(xié)作翻譯,，轉(zhuǎn)載請注明來源,。如果你對本文的翻譯有建議，歡迎提交 Pull Request ,。 讓我們來聊聊部署無論你何時對自己的代碼庫做出改動,，總會伴隨著要破壞一些東西的風(fēng)險。 沒有人喜歡宕機, 沒有人喜歡暴躁的用戶, 也沒有人喜歡生氣的經(jīng)理,，所以部署新代碼到生產(chǎn)環(huán)境變成頗具壓力的一個環(huán)節(jié),。 你完全沒必要對它有壓力，我將在這里重復(fù)一遍又一遍這句話：
部署新功能到生產(chǎn)環(huán)境中應(yīng)該像在 Hacker News 開始一場關(guān)于 用 spaces 還是 tabs 的口水戰(zhàn)一樣簡單,。它應(yīng)該足夠簡單到讓新員工理解,，它應(yīng)該為防止錯誤而生，它應(yīng)該在第一個最終用戶看到新代碼前被很好地測試過,。 這是一篇高層次談?wù)摬渴鸬奈恼?，包含了：協(xié)作，安全和速度等,，在底層方面也講了很多,，但這些都是很難跨語言進行概括,，并且說實話,，比起在高層次技術(shù)方面有很多更密切的問題要去解決，我更喜歡談?wù)搱F隊如何協(xié)同工作,，而部署是與其他人協(xié)作最關(guān)鍵的一部分,。我認為你值得花時間并不時地來評估你團隊的狀況。 有很多來自我在 GitHub 任職 5 年的經(jīng)驗,，和去年我與大大小小科技公司提供建議和咨詢的經(jīng)驗,，對在提高他們的部署工作流程的重點上（已經(jīng)從“非常可敬”到歸納于“我覺得這服務(wù)器已經(jīng)著火了”）,。我特別推薦一個初創(chuàng)公司,， Dockbit ，其產(chǎn)品是旨在正視部署中的合作,，等等,。這篇文章來源于許多關(guān)于我和它們團隊的談話,，我認為寫下來許多部署難題中的不同部分會大有益處的。 我很感激一些來自不同公司的朋友給予這篇文章的校隊和幫忙,，并提供各自在部署上不同的觀點： Corey Donohoe (Heroku) ,， Jesse Toth (GitHub) ， Aman Gupta (GitHub) ,， 和 Paul Betts (Slack) ,。我不斷的發(fā)現(xiàn)不同的公司可能采取很有趣的不同路徑，但一般都集中在合作,，風(fēng)險和謹慎這種基礎(chǔ)方面,，我覺得有東西在這里具有普遍性。 不管怎么說,，對于這個漫長的導(dǎo)語我感到很抱歉,，但無論如何這篇文章將是很長的，請盡力讀完吧, lol. 目錄
難道部署不是一個已經(jīng)解決的問題嗎?如果你說的是拉取代碼并將它們傳送到不同的服務(wù)器上,，那么事情已經(jīng)解決的很漂亮并且這些事情相當無聊。你已經(jīng)獲得了 Ruby 中的 Capistrano（一種遠程服務(wù)器自動化工具）,， Python 中的 Fabric(Python 的一個類庫以及命令行工具),，Node 中的 Shipit （Javascript 寫的一個通用自動化和發(fā)布工具）,，以及所有的亞馬遜云服務(wù)，甚至是 FTP 也貌似會存在好幾個世紀,，因此工具現(xiàn)在真的不是問題,。 如果我們此時有了相當不錯的工具，為什么部署會出錯呢,？為什么人們總是發(fā)布 bug 呢,？為什么總是存在宕機的情況？我們可都是寫完美代碼的完美程序員啊,，這真是見鬼了,。 很明顯，事情總是始料未及地發(fā)生,，所以我認為部署應(yīng)該是中小型公司應(yīng)關(guān)注的有趣領(lǐng)域,，其他領(lǐng)域沒有如此好的投入產(chǎn)出比。你可以做好盡早處理和應(yīng)對問題的工作流程嗎,？你可以使用不同的工具來更簡單地進行協(xié)助部署嗎,？
我對很多很多創(chuàng)業(yè)公司講,，過去的幾年，還沒有一個從組織的角度看上去“好的”部署工作流,。 你無需負責(zé)部署的專人,，無需特定一個部署日期，無需在每次部署時動用所有人手,。你只需要采取一些聰明的辦法,。 在一個好的基礎(chǔ)上開始。在跑之前你必須走起來,。我認為初創(chuàng)公司有一個很時髦的方面就是它們都用著最酷并且最新的部署工具,，但是當你切進去觀察他們的處理時，會發(fā)現(xiàn)他們花了 80% 的時間在處理基礎(chǔ)上,。如果他們從開始時就是流水化的,，每件事都會恰當?shù)靥幚聿⑶腋鼮檠杆佟?/p> 測試測試是前期一個最簡單的地方。在一些淺顯的依賴處理中這不是一個必需的步驟,，不過卻對其著有著巨大的影響。 這里很多技巧取決于你的語言,，平臺或者框架,，不過普遍的建議是測試你的代碼 ，并提高測試速度,。 我最喜歡引用 Ryan Tomayko 在 GitHub 的內(nèi)部測試文檔里寫的：
所以以一個好的基礎(chǔ)開始：做個好的測試,，別吝嗇這點，因為它影響一切的方向,。 一旦你開始有一個值得依靠的質(zhì)量測試套件,，盡管在開始時得花錢。如果你有任何形式的收入或者你們幕后團隊的資助,，幾乎頭號你應(yīng)該花錢的地方就是你應(yīng)該運行測試的地方,。如果你使用 Travis CI 或者 CircleCI ，如果你能運行并行編譯構(gòu)建那么就重復(fù)今天所做的,。如果你需要在特定的硬件上運行,，那就買巨大的服務(wù)器。 我見過一些公司通過遷移到更加快的測試套件上使其獲得了最重要的生產(chǎn)力優(yōu)勢,，而你也能賺到,，因為它影響迭代反饋周期，縮短依賴時間,，增加開發(fā)者的幸福感并且使其成為一種慣性,。在問題解決方案上花錢吧：因為服務(wù)器很便宜，但程序員卻不,。 我在 Twitter上 做過一個非正式的投票 問我的 followers 他們的測試套件究竟跑得有多快,。誠然，很難解釋那些微小服務(wù),，語言差異上居然有驚人數(shù)目的人從來沒有做過測試,。不過在全棧和更快的單元測試者對決中，它表現(xiàn)的還是非常明顯,。大多數(shù)人在 push 后至少要等待5分鐘才能看到構(gòu)建狀態(tài),。 快究竟指多快呢？ 當我在 GitHub 時,，測試一般在 2-3 分鐘內(nèi)跑完,。我們并沒有很多集成測試，所以允許以相對較快的速度測試,，但是實際上你測試的越快,，你就能越快的得到開發(fā)人員的循環(huán)反饋。 有許多的項目旨在幫助你并行化構(gòu)建項目,。在 Ruby 里有 parallel_tests 和 test-queue ,。比如你的測試沒有相互完全獨立，以不同的方式編寫測試是一個很好的方法,，如果情況相反,，你也應(yīng)該好好處理它。 Feature Flags這一切的另一個方面是開始看你的代碼并且把它轉(zhuǎn)化來支持多渠道部署代碼路徑,。 重復(fù)一遍,，我們的目標是你的部署應(yīng)該盡可能單調(diào),，直接，無壓力,。部署任何新代碼的自然壓力是代碼運行出你無法預(yù)見的問題,，你最終影響到用戶的行為（即他們經(jīng)歷的停機時間和錯誤）。即使你有宇宙中最好的程序員,，糟糕的代碼將最終被部署,。不管這些壞代碼是影響 100% 的用戶或只是一個對你們非常重要的用戶。 用一個簡單的方法來處理,，那就是 Feature Flag ,。 Feature Flag 已經(jīng)出現(xiàn)很久了，至少,，技術(shù)上講,，是自從 if 語句發(fā)明開始的，而我記得第一次真正聽到有公司的使用 Feature Flag 是 Flickr 在 2009 年的一篇文章,。Flipping Out
只有你可以看到,，或只有你的團隊可以查看 flags,，或所有員工都能看是兩件不同的事：你可以在現(xiàn)實世界使用真實的數(shù)據(jù)測試代碼，并確保一切工作正常,；你還可以得到真正的關(guān)于該功能正式發(fā)布時得到關(guān)于性能和風(fēng)險的 benchmarks,。 所有這一切的對你準備部署新的功能是大大有利的，你需要做的就是修改一行代碼為 true ,，然后每個人都看到了新的代碼,。這使得通常嚇人的新版本部署變?yōu)闉閱握{(diào)，直接,，且無壓力,。 可查驗的正確的部署作為一個額外的步驟，F(xiàn)eature Flag 提供了一個很好的方式來證明你的即將代碼部署不會對性能和可靠性產(chǎn)生不利影響,。最近幾年一些新的工具能幫助你做到這個,。 我在幾年前的演講文章 《Move Fast and Break Nothing》 中談過，它的主要內(nèi)容是在生產(chǎn)環(huán)境運行 Feature Flag 的兩個代碼路徑中,，并且只返回舊代碼的結(jié)果,，觀察你引進的新代碼與你即將更換的新代碼的表現(xiàn)。一旦你有了這些數(shù)據(jù),，你可以確保你不會破壞任何事情,。部署將變得單調(diào)，直接,，無壓力,。 GitHub 上一個叫做 Scientist 的開源 Ruby 庫能抽象的幫助你很多。這個庫已經(jīng)這點上被移植到最受歡迎的語言上,，所以如果你感興趣,，它可能很值得你花時間去看一看。 另一種方法是灰度發(fā)布,。一旦你對要部署的代碼是準確無誤充滿信心,，首先你仍然謹慎地僅公開到一小部分用戶來進行雙重檢查和三重檢查，直到?jīng)]有產(chǎn)生什么破壞,。破壞 5% 用戶的體驗比破壞 100% 用戶的體驗要好得多,。 有大量旨在幫助你的庫，從 Ruby 中的 Rollout ,， Java 中 Togglz ,，到 JavaScript 中的 fflip ，和許多其他的,。還有很多初創(chuàng)公司在為這個問題提供解決方案,，比如 LaunchDarkly 。 另外值得一提的是,，這并不僅僅是 Web 的事情,。本地應(yīng)用也可以從中獲益良多。粗略看下 GroundControl 這個 iOS 中處理表現(xiàn)的庫就懂了,。 在代碼構(gòu)建上自我感覺良好,？贊,，我們現(xiàn)在來跳出這點,，開始討論下部署。 用分支管理很多圍繞部署的組織問題被部署者與其他人缺少溝通阻礙著,。你需要每個人了解了你即將上線的代碼的方方面面,，在做這個同時避免踩到她人的腳趾,。 這里有幾個可以幫到你的有趣的方式，它們都取決于部署的最簡單元：分支,。 代碼分支分支,，我是指 Git，Mercurial 等版本控制系統(tǒng)的分支,。先切出一個分支,，在該分支上編程，然后推送代碼到你喜愛的代碼托管平臺（如 GitLab,，Bitbucket,，Coding 等） 代碼評審代碼評審這個話題太大,，太復(fù)雜，且依你的團隊和風(fēng)險狀況不同,。我認為這里有幾個重要的問題需要所有的團隊去思考：
分支和部署節(jié)奏這里有個關(guān)于代碼評審的老段子,。無論何時你開啟了一個關(guān)于 6 行代碼的評審請求,，你總會得到很多同事關(guān)于這 6 行代碼的指指點點。但當你 push 了一個花了幾周時間的代碼分支,，你常常會得到一個很快回復(fù)的：贊,，我看行,！ 基本上，程序員常常都是一群很討厭的懶蟲,。 但你可以利用其作為你的優(yōu)勢,，通過：使用盡快，較小的分支和 Pull Request,。讓代碼小到可以很容易讓人隨時切入并進行評審,。如果你寫了大型的分支,，這需要別人花很長時間去 review,，同時拖慢了整個開發(fā)的進度。 如何讓代碼更??？這時之前說的 feature flags 就派上用場了。當 2014 年我團隊的三個人重建 GitHub 的 Issues 時,，我們向 Production 推送了大約上百數(shù)量的使用 Feature Flag 的小型 Pull Requests,。我們部署了很多小單元（在其“完美”之前）。這讓代碼評審更簡單,，同時讓部署更快,，更早看到線上的產(chǎn)品狀況。 你需要快速并頻繁地部署,。十人規(guī)模的團隊可以每天無憂地部署至少 7-15 個分支,。重復(fù)一遍，diff 越小,，部署就越單調(diào),，越直接，越無壓力,。 部署分支當你準備好部署你的新代碼,，你應(yīng)該總是在合并代碼前部署你的分支。注意"總是",。 查看整個代碼庫作為事實的記錄,。你的 master 分支（或你指定的任何的默認主分支）應(yīng)該作為你的生產(chǎn)環(huán)境的絕對鏡像。換句話說,，你需要確保你的主分支是“沒問題的”,，就是該分支沒有任何已知的問題。 分支是個大問題,。如果你合并你的分支到 master 然后就部署 master 分支,，你無法簡單地判斷代碼是否正常，“沒問題”分支是無需做任何惡心的代碼回滾操作的分支,。 這就是為什么你的部署工具應(yīng)該支持你部署分支是很重要的,。一旦你確認你的性能沒有波動，沒有穩(wěn)定性問題,，功能可用性在預(yù)期內(nèi),，你就可以 merge 它了。這么做的原因不是為了確保事情可行,，而是防止事情不可行,。當其出錯時，你的解決方案應(yīng)該是單調(diào),，直接且無壓力的：重新部署 master 分支即可,。就是這樣。你回到了“沒問題”的狀態(tài),。 自動部署重要的是要對你的“已知狀態(tài)”有清晰的定義,，最簡單的方法就是定一個簡單的不出錯的規(guī)則：
這里有很多工具平臺可用,，如 Heroku 可以自動部署最新分支。CI 工具如 Travis CI （譯者注：國內(nèi)有 ）也可以幫你自動部署,?；蛩接胁渴鸬?Heaven 和 hubot-deploy-tools （我們稍后會提到）也可以幫到你。 自動部署在你 merge 你工作的分支到 master 分支時也有幫助,。你的工具應(yīng)該可以選取一個新的修訂并重新再次部署網(wǎng)站,。盡管軟件內(nèi)容沒變（你在有效的部署同一套代碼），SHA-1 值變化了,，這使生產(chǎn)環(huán)境的已知狀態(tài)變得更加明確（再次重申下,，master 分支是已知狀態(tài)）。 藍綠部署Martin Fowler 曾經(jīng)在 2010 年的文章推崇過 藍綠部署（很值得一讀）,。在其中,，F(xiàn)owler 談?wù)摰绞褂脙煞N理想的生產(chǎn)環(huán)境的理念，即他說的“藍”和“綠”,。藍意味著在線的生產(chǎn)環(huán)境,，綠代表空閑的生產(chǎn)環(huán)境。你可以部署到綠色集群,，確認一切正常運行后,，通過無縫切換（如負載均衡）切換到藍色集群,。如此，生產(chǎn)環(huán)境收到了沒有風(fēng)險的代碼,。
這是一個非常強大的想法,，而日益普及的虛擬化,，容器技術(shù)和（可以很容易地扔掉，被遺忘的）自有環(huán)境使它變得更加強大,。除了一個簡單的藍色/綠色的部署,，你也可以讓生成產(chǎn)環(huán)境流動起來，因為一切都是虛擬的,。 這里有很多解決方法,，從災(zāi)備恢復(fù)到在用戶看到它前附加時間測試關(guān)鍵功能，但我最喜歡的是附加功能使用代碼,。 使用新代碼是在產(chǎn)品開發(fā)周期非常重要的。當然,，很多問題應(yīng)提前在代碼審查或通過自動測試找到了,，但如果你正在嘗試做真正的產(chǎn)品，有時很難預(yù)測直到你已經(jīng)長時間試過了真實的數(shù)據(jù),。這就是為什么藍綠部署比有一個簡單的臨時服務(wù)器更重要,，其數(shù)據(jù)可能過時了或完全捏造。 更重要的是,，如果你需要你的代碼部署到特定的環(huán)境中,，你就可以在早期開始就引入不同利益相關(guān)者。不是每個人都有技術(shù)能力把你的代碼拉取到他們的計算機上,，并在本地安裝你的代碼 - 而且這也是不應(yīng)該的,！比如，如果你能給你的會記部門展示你的新的上線情況的屏幕,，在整個公司看到它之前,，他們可以給你一些關(guān)于它的現(xiàn)實反饋，這可以幫你在早期找到很多的錯誤和問題,。 Heroku Pipelines不管你用不用 Heroku,，看一下他們生態(tài)系統(tǒng)中的“Review Apps”理念：apps 直接從一個 Pull Request 進行部署，直接上線而不是截圖或大幅的關(guān)于“這就是它上線后的樣子”的描述,。讓更多人盡早參與進來而不是你之后試圖用爛的產(chǎn)品說服他們,。 控制部署流程你看，當我在談一個創(chuàng)業(yè)公司的組織方式時,，我是完全嬉皮自由雅痞的：我篤信開發(fā)者的自主性,，用一種自下而上的方法去開發(fā),，注重人而不是管理。我認為這會讓大家更快樂且讓產(chǎn)品更好,。但在部署時,，嗯哼，這是非常重要的,，屬于 all-or-nothing 的需要做好的事情,，所以我覺得這里加入管控是合理的。 幸運的是,，部署工具就是加入限制,，從而把大家從壓力中解放出來，所以如果你做對了將大大獲益,，而不是常人說的這將是阻礙,。換句話說，你的流程應(yīng)該促使事情搞定,，而不是阻礙它,。 審計跟蹤我驚訝一些竟然不可以很快拿到審計日志的創(chuàng)業(yè)公司。盡管可能會有一些聊天記錄可查,，但這不應(yīng)該是你需要時拿不出來的東西,。 審計跟蹤的好處就是你預(yù)見到的：你可以找出是何時何地何人部署的。當你之后遇到問題時,，你可以回滾到某一節(jié)點,，這將節(jié)省不少時間。 很多服務(wù)都提供了這類的部署日志,。如 Amazon CodeDeploy 和 Dockbit,，提供了廣義上的部署工具并提供了很好的追蹤工具。GitHub 杰出的部署 API （譯者注：Coding.net 也提供了 部署 API）也是很好的從 Pull Request 部署集成到你的外部系統(tǒng)的好辦法,。 GitHub 的開發(fā) API如果你在專家模式,，在你的部署和部署時間需要插入很多數(shù)據(jù)庫和服務(wù)，如 InfluxDB,，Grafana,，Librato 或 Graphite?？梢栽诮o定指標和部署層指標中對比是非常強大的：起初看到一個意外的指標增加或許讓你好奇,，但當那是一次部署在發(fā)生時，你就不會感到意外了,。 部署鎖定如果你走到了在一個代碼庫中有很多人的這一步,，你自然會遇到有很多人在某時都準備部署各自代碼的狀況。當然同時部署多個分支到生產(chǎn)環(huán)境是可行的,，但我建議,，當你走到這一步時,，你需要些處理這種情況的工具。部署鎖定就是我們要了解的第一個東西,。 部署鎖定基本是你已經(jīng)預(yù)料到的東西：鎖定生產(chǎn)環(huán)境以便大家可以依次進行部署,。這里有很多方法可行，但最重要的是你要讓這 可見,。 實現(xiàn)這一目標的最簡單辦法就是通過聊天,。一個常見的方式可以是設(shè)置部署命令鎖定生產(chǎn)環(huán)境，比如： i.e., 這使大家都明白你在部署什么,。我見過一些使用 Slack 的公司在 Slack 的部署聊天室里說：我在部署...,！我覺得這是沒有必要的，這只會分散你的同事,。這里只要把信息扔進聊天室就夠了,。如果你之后忘了做也可以添加一條額外命令讓系統(tǒng)返回目前生產(chǎn)環(huán)境的狀態(tài)。 這里有很多簡單方法可以把這套工作流插入你的聊天室,。Dockbit 有一個 Slack 集成,。也有一個開源解決方案叫作 SlashDeploy 可以集成 GitHub 和 Slack。（譯者注：國內(nèi)有 bearychat.com 提供了類似服務(wù)） 我還見過一些特制的關(guān)于這一步的網(wǎng)頁版工具,。Slack 有個自定義的內(nèi)部 App 提供了可視化的部署,。Pinterest 有一個開源的基于網(wǎng)頁的部署系統(tǒng)。你可以將鎖定的理念延伸到其他方面,，這取決于如何使你的團隊最高效工作。 一旦部署分支被 merge 到 master 分支,，生產(chǎn)環(huán)境應(yīng)該自動解鎖以便下一個人進行操作,。 這里也有一定的鎖定禮儀。你當然不希望大家等待一個粗心的程序員忘記了解鎖生產(chǎn)環(huán)境,。自動解鎖工具就派上用場了,，比如，你也可以設(shè)置定時提醒部署人員其生產(chǎn)環(huán)境是否被鎖定超過了 10 分鐘,。宗旨就是：拉完屎趕緊走,。 部署隊列一旦你有很多部署要安排且你有很多人員準備部署，你顯然會有一些部署爭論,。對于這一點,，從你內(nèi)心深處的英國紳士特色中選擇，形成一個部署隊列,。 一個部署隊列有幾個部分：1）如果需要等待,，把你的名字添加到末尾，2）允許有人插隊 （有些非常重要的部署需要立即執(zhí)行,，你需要允許這樣做） 部署隊列的唯一問題就是有太多人排隊部署了,。GitHub 從過去一年至今都面臨這個問題,；在周一人人都想部署他們的變更，部署列表看起來可以持續(xù)一個小時或更久,。我不是特別提倡微服務(wù),，但我認為部署隊列有一個好處就是你可以從雄偉的巨石中劈東西了。 權(quán)限有很多方法可以限制使用部署權(quán)限的人,。 兩步驗證是一個選項,。最好你的雇員聊天賬號不會被公開，最好他們在他們電腦上有其他安全措施（全盤加密,，強密碼等等）,，但是如果你要安心的話，最好要求他們開啟兩步驗證,。 或許你已經(jīng)有提供兩步驗證服務(wù)的聊天服務(wù)商,，如 Campfire 和 Slack。（譯者注：Coding.net 也提供了 兩步驗證 ） 如果你需要在部署前進行兩步驗證,，你可以在其流程中增加兩步驗證,。 另一種可行的處理方法是，我稱權(quán)限外的調(diào)查員為“騎獵槍”,。我見過很多擁有正式或非正式的流程或工具去保證至少有一位高級開發(fā)人員參與每一步部署,。這里沒有理由不這么做，比如,，要求你的部署人員和高級開發(fā)人員（騎獵槍）去確認代碼可以部署,。 欣賞并檢驗?zāi)愕墓ぷ?/h4>一旦你部署完你的代碼，便是時候開始驗?zāi)闶欠裾娴淖隽四闼胱龅摹?/p> 檢查你的 Playbook無論是更新前端,、后端或其他任何代碼,，每次部署都必須符合同一個策略方針。你必須查看網(wǎng)站是否還正常運行著,，是否性能突然變得更糟糕,，是否產(chǎn)生更多誤碼率，亦或者有更多反饋的問題等等,。所以說精簡那個策略方針將對你非常有利,。 對于上述的不同方面，如果多個信息來源,，試著比如在最終確認部署的時候給每個儀表盤中加一個鏈接,。這樣每次都能提醒大家觀察并驗證這些變更是否對度量指數(shù)產(chǎn)生了負面影響。 理想狀態(tài)下,，應(yīng)從一個來源里獲取信息,。這樣更容易指引，比如一個新員工在第一次部署的時候該觀察重要的度量指數(shù),。比如 Printerest 的 Teletraan 在一個界面里就包含了所有的信息,。 度量指數(shù)有很多可以收集的度量指數(shù)將有助于你判斷剛剛部署得是否成功,。 當然最顯著的是誤碼率。如果它突然急速上升,，意味著你可能得重新部署 master 分支并且修復(fù)這些問題,。這些過程可以自動化實現(xiàn)，甚至可以設(shè)定一個閾值,，如誤碼率超了就自動重新部署,。如果你確定 master 是一個對你來說熟知并且可以回滾的分支，那么自動回滾將變得更容易,，一旦你部署后就觸發(fā)大量異常則自動回滾部署,。 部署本身也是個很有意思的度量，值得放在手上,。一個很好的例子就是縱覽過去一年的部署情況,，可以幫助你了解部署的節(jié)奏是在放大，或者讓你了解它慢下來的原因,。你可以進一步收集是誰在部署,，誰導(dǎo)致了錯碼，并開發(fā)一種能夠檢測團隊開發(fā)者是否可靠的方法,。 部署后的清理最后一步需要做的家務(wù)活就是清理,。 Feature Toggles 是最糟糕的技術(shù)債之一 對這進行了討論，雖然這個標題有點激進,。如果你正在構(gòu)建一些有 feature flags 以及人員發(fā)展的項目,，你將面臨長期使你代碼庫的變得更復(fù)雜化的風(fēng)險：
你不需要部署完就立刻清理；如果你有一個新功能或者 bug 修復(fù)的需求,，你應(yīng)該花時間在監(jiān)測系統(tǒng)指標,，而不是立刻刪除代碼，盡管部署后不久你還是得這樣做,。如果你有一個重大版本發(fā)布,， 你可以在一天或一星期后回顧并刪除那些已經(jīng)不用的代碼。我喜歡做的一件事就是準備兩個 pull request：一個是切換 Feature flags （比如,，開放該功能給所有人）,，另一個是清除所有的你引入的冗余代碼,。當我確保我沒破壞任何事情并且看上去不錯的話，我就可以合并第二個 pull request 而不需再更多的考慮或開發(fā),。 你還需要給自己慶祝一番：因為這個終極信號意味著你們已經(jīng)成功地完成了這個項目,。所有人都會喜歡看到 diff 幾乎都變紅的狀態(tài)，刪除代碼的確是件很開心的事情,。 刪除分支當你完成任務(wù)后,，你同樣可以刪除分支，這肯定是不會錯的,。但如果你用的是 GitHub 的 pull request,，你通常可以保留刪除的分支,，這樣相當于從分支列表中刪除了該分支,，但其實不會有任何的數(shù)據(jù)丟失。這個過程同樣也可以自動完成：定期執(zhí)行一個腳本,，檢查你那些陳舊的已合并到 master 的分支并且刪除它們,。（譯者注：Coding.net 的 Merge Request 也提供了 merge 后自動刪除分支功能） 整個球賽我只對兩種事情感到情緒激動：一個是一張動人的照片：山頂上一只金毛尋回犬倚著它最好的朋友，面朝大海,，看夕陽西下,；還有就是部署工作流。我如此關(guān)心這件事是因為它是整個比賽最關(guān)鍵的一部分,，在一天結(jié)束的時候,，我只關(guān)心兩件事情：同事的感覺是怎么樣的，我工作的產(chǎn)品是怎么樣的,。對我來說其他一切皆源于這兩方面,。 部署可以造成壓力和挫折，尤其當你的公司開發(fā)節(jié)奏是遲緩的,，也可以減緩和阻止你添加新功能,、為用戶修復(fù) BUG。 我認為思考這些是值得的,，優(yōu)化自己的工作流也是值得的,。花一些時間讓自己的部署變得盡可能單調(diào),、直接,、無壓力，是會得到回報的,。 （完） 你可能會感興趣的文章：
|
|
|
