在本文中，開發(fā)環(huán)境是指可以在部署之前測(cè)試代碼更改的沙箱，不是 Eclipse 或 Microsoft Visual Studio 這樣的集成開發(fā)環(huán)境（IDE）。

　　本文最初發(fā)布于 Slack 官方博客，由 InfoQ 中文站翻譯并分享。

　　對(duì)我來說，開發(fā)環(huán)境一直是個(gè)謎。盡管我在 Slack 的第一天就了解了它們，并在過去三年幾乎每天都在使用它們，但我從未真正地理解它們。

　　半年前，我定了一個(gè)目標(biāo)，要全面了解開發(fā)環(huán)境。我與 Slack 一些最資深的工程師進(jìn)行了交流，研究了無數(shù)文檔，篩選了多年的 Slack 對(duì)話。從中，我發(fā)現(xiàn)了一個(gè)關(guān)于 Slack 開發(fā)環(huán)境隨時(shí)間演進(jìn)的有趣旅程。

　　為什么需要開發(fā)環(huán)境？

　　開發(fā)環(huán)境是我們可以自由修改的應(yīng)用程序副本。它們的主要價(jià)值是讓我們可以在不影響實(shí)際用戶或不泄露真實(shí)數(shù)據(jù)的情況下測(cè)試應(yīng)用程序更改。

　　開發(fā)環(huán)境使我們能夠快速迭代，因?yàn)樵谏厦鏈y(cè)試更改非常快也非常簡單。通過它，我們可以很容易地與他人共享更改以供審核。

　　總之，開發(fā)環(huán)境極大提高了開發(fā)速度和安全性。

　　后臺(tái)是什么樣子？

　　Slack 的開發(fā)環(huán)境是我們的應(yīng)用程序在遠(yuǎn)程服務(wù)器（準(zhǔn)確地說是 Amazon EC2 實(shí)例）上的副本。這些實(shí)例運(yùn)行 Slack 應(yīng)用程序及其所依賴的許多服務(wù)。

　　每個(gè)開發(fā)環(huán)境都有自己的 Slack 子域，我們可以在瀏覽器中查看我們的更改。開發(fā)環(huán)境中的任何更改都不會(huì)影響實(shí)際用戶，因?yàn)樗鼈冏约河幸惶着c生產(chǎn)環(huán)境隔離的基礎(chǔ)設(shè)施（例如數(shù)據(jù)庫）。

開發(fā)環(huán)境和生產(chǎn)環(huán)境是完全隔離的。（圖標(biāo)來自Flaticon，由Freepik提供）

　　遠(yuǎn)程開發(fā) vs. 本地開發(fā)

　　在 Slack，我們是遠(yuǎn)程開發(fā)，這意味著我們的開發(fā)環(huán)境在服務(wù)器上。另一個(gè)選項(xiàng)是在我們的個(gè)人電腦上進(jìn)行本地開發(fā)。對(duì)于小型項(xiàng)目來說，本地開發(fā)非常好，因?yàn)樗俣瓤欤也恍枰?lián)網(wǎng)。然而，對(duì)于較大的項(xiàng)目，遠(yuǎn)程開發(fā)環(huán)境則有顯著的優(yōu)勢(shì)。

　　首先，我們不必在本地設(shè)置 Slack 應(yīng)用程序。Slack 的架構(gòu)非常復(fù)雜，它依賴于許多不同的服務(wù)，不用在本地設(shè)置是非常有價(jià)值的。

　　其次，如果一項(xiàng)更改在開發(fā)環(huán)境中有效，那么它在生產(chǎn)環(huán)境中也很可能有效，因?yàn)槲覀儗㈤_發(fā)環(huán)境配置為生產(chǎn)環(huán)境的鏡像。對(duì)于使用時(shí)間特別長的開發(fā)環(huán)境，可能仍然會(huì)出現(xiàn)某種程度的偏差，但是，出現(xiàn)這種偏差的可能性以及偏差的幅度，都要比在本地使用單獨(dú)的機(jī)器進(jìn)行開發(fā)時(shí)小得多，本地開發(fā)經(jīng)常會(huì)導(dǎo)致配置不一致。

　　第三，遠(yuǎn)程開發(fā)環(huán)境不依賴于可能會(huì)崩潰或落后的個(gè)人計(jì)算機(jī)。云硬件更便宜、更有彈性，而且可伸縮。此外，它們使我們很容易在多臺(tái)機(jī)器上進(jìn)行開發(fā)，并與隊(duì)友共享工作以供審核。

　　隨著互聯(lián)網(wǎng)變得越來越快、越來越可靠，遠(yuǎn)程開發(fā)越來越有意義。

　　如何使用開發(fā)環(huán)境？

　　我們最好通過一個(gè)例子來看下 Slack 的開發(fā)環(huán)境工作流。假設(shè)出于某種原因，我們想測(cè)試一個(gè)使用了紫色 Comic Sans 字體、全大寫的 Slack 主頁版本。

　　我們首先創(chuàng)建一個(gè)特性分支，然后使用一個(gè)名為 slack sync-dev 的命令行工具將其追加到開發(fā)環(huán)境中。它會(huì)隨機(jī)預(yù)定一個(gè)開發(fā)環(huán)境，然后將本地更改同步到上面。這樣，我們本地編輯的任何內(nèi)容在保存時(shí)都會(huì)自動(dòng)傳輸?shù)介_發(fā)環(huán)境。

　　slack sync-dev只是對(duì)兩個(gè)著名的實(shí)用工具fswatch（檢測(cè)更改）和rsync（傳輸更改）的封裝。

同步到開發(fā)環(huán)境

　　如果做了任何前端更改，我們就必須使用 webpack（我們用作構(gòu)建系統(tǒng)的一個(gè)開源工具）在本地構(gòu)建它們。命令 slack run buildy:watch 構(gòu)建我們的前端資產(chǎn)，并通過本地主機(jī)將它們提供給我們的開發(fā)環(huán)境。

　　完成后，我們可以導(dǎo)航到 dev575 子域。

無疑右邊的版本更引人注目！

　　現(xiàn)在，我們可以在頁面上找 Bug，調(diào)整更改，并與他人共享以供審核。

　　前端更改是由個(gè)人計(jì)算機(jī)構(gòu)建并提供。如果想讓其他人在我們關(guān)機(jī)后還能夠看到這些更改，我們就必須生成一個(gè)靜態(tài)構(gòu)建，在開發(fā)環(huán)境中構(gòu)建前端資產(chǎn)，而不是在本機(jī)。

　　為什么在本機(jī)構(gòu)建前端？

　　2017 年，當(dāng)首次引入 webpack 時(shí)，我們是在開發(fā)環(huán)境中遠(yuǎn)程構(gòu)建前端更改。當(dāng)有人更改了前端并同步后，開發(fā)環(huán)境就會(huì)自動(dòng)重新構(gòu)建前端資產(chǎn)。

　　然而，隨著代碼庫的增長，webpack 變得越來越消耗資源。構(gòu)建會(huì)消耗整個(gè)實(shí)例的內(nèi)存。當(dāng)時(shí)，多個(gè)開發(fā)人員在同一個(gè)實(shí)例上工作，他們經(jīng)常被打斷。因此，我們將 webpack 轉(zhuǎn)移到了本地機(jī)器上。

　　現(xiàn)在，每個(gè)實(shí)例只有一個(gè)開發(fā)環(huán)境，而有了更高級(jí)的實(shí)例，就完全有可能將 webpack 移回我們的開發(fā)環(huán)境，開發(fā)人員將獲得更流暢的體驗(yàn)。但目前，系統(tǒng)運(yùn)行速度很快，而且可擴(kuò)展，所以我們覺得沒必要去修復(fù)沒壞的東西。

　　改進(jìn)命令行工具

　　我們討論一下命令行工具。上文已經(jīng)介紹了一些，比如 slack sync-dev。Slack 離不開這些工具，因?yàn)樗鼈冏岄_發(fā)更快、更簡單。

　　早期，在還沒有 slack sync-dev 的時(shí)候，我們不得不手動(dòng)地將我們的更改復(fù)制到開發(fā)環(huán)境中，這很耗時(shí)，而且容易出錯(cuò)。現(xiàn)在，我們有 60 多個(gè)命令行工具，這簡化了許多這樣的日常任務(wù)。

　　其他的例子包括 slack bo-me（它在當(dāng)前開發(fā)環(huán)境中創(chuàng)建一個(gè) bot 用戶）以及 slack tail-dev（它跟蹤當(dāng)前開發(fā)環(huán)境中的遠(yuǎn)程日志）。如果你想進(jìn)一步了解我們的開發(fā)工具，請(qǐng)查看我們 2016 年發(fā)表的博文。

　　擴(kuò)展我們的開發(fā)環(huán)境

　　2014 年的時(shí)候，我們只有一個(gè)開發(fā)環(huán)境供所有人使用。如果有人破壞了這個(gè)環(huán)境，其他人就無法測(cè)試他們的更改了。這在當(dāng)時(shí)并不是什么大問題，但隨著 Slack 的發(fā)展，我們不得不增加開發(fā)環(huán)境。到 2019 年底，我們已經(jīng)維護(hù)了 550 個(gè)開發(fā)環(huán)境，足夠每個(gè) Slack 工程師都連接到一個(gè)不同的開發(fā)環(huán)境。

　　不過，這一增長趨勢(shì)并沒有持續(xù)下去，事實(shí)上，2020 年就完全逆轉(zhuǎn)了。在討論原因之前，讓我們先看看另一個(gè)隨時(shí)間變化的有趣指標(biāo)：每個(gè) EC2 實(shí)例上開發(fā)環(huán)境的數(shù)量。

　　隨著時(shí)間的推移，數(shù)值在下降，因?yàn)槲覀兿雽㈤_發(fā)環(huán)境彼此隔離開來。當(dāng)多個(gè)環(huán)境共享同一個(gè)實(shí)例時(shí)，如果有一個(gè)開發(fā)人員在其中一個(gè)環(huán)境上運(yùn)行一個(gè)內(nèi)存密集型進(jìn)程，就會(huì)降低其他所有環(huán)境的運(yùn)行速度。

　　這是一個(gè)折衷——每個(gè)實(shí)例上的開發(fā)環(huán)境數(shù)少了，就意味著我們需要購買更多的 EC2 實(shí)例。此外，這些實(shí)例是靜態(tài)托管的，因此，我們需要花大量的工程時(shí)間來提供新的實(shí)例以及刪除損壞的實(shí)例。更糟糕的是，長期運(yùn)行的實(shí)例會(huì)隨著時(shí)間的推移而變得混亂，而其行為將不再可靠。

　　為了解決這些問題，我們創(chuàng)建了一個(gè)按需提供開發(fā)實(shí)例的新系統(tǒng)，逆轉(zhuǎn)了第一個(gè)圖表中所顯示的增長趨勢(shì)。我們按需提供新實(shí)例，而不是保持?jǐn)?shù)百個(gè)實(shí)例同時(shí)運(yùn)行。一旦開發(fā)人員完成了測(cè)試，他們使用的實(shí)例將被自動(dòng)刪除。有了這個(gè)系統(tǒng)，我們就可以更有效地使用開發(fā)環(huán)境。我們將在下一篇文章中深入討論這些擴(kuò)展方面的演進(jìn)，請(qǐng)繼續(xù)關(guān)注！

　　作者介紹：

　　Michael是 Slack 平臺(tái)團(tuán)隊(duì)的一名軟件工程師。他已在 Slack 工作了將近 3 年。期間，他參與了各種各樣的項(xiàng)目，包括面向用戶的功能、API 基礎(chǔ)設(shè)施和擴(kuò)展實(shí)驗(yàn)。

　　英文原文：Development Environments at Slack

總結(jié)

以上是生活随笔為你收集整理的Slack 的开发环境是如何演进的？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。