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

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

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

　　半年前，我定了一個目標，要全面了解開發環境。我與 Slack 一些最資深的工程師進行了交流，研究了無數文檔，篩選了多年的 Slack 對話。從中，我發現了一個關于 Slack 開發環境隨時間演進的有趣旅程。

　　為什么需要開發環境？

　　開發環境是我們可以自由修改的應用程序副本。它們的主要價值是讓我們可以在不影響實際用戶或不泄露真實數據的情況下測試應用程序更改。

　　開發環境使我們能夠快速迭代，因為在上面測試更改非?？煲卜浅：唵?。通過它，我們可以很容易地與他人共享更改以供審核。

　　總之，開發環境極大提高了開發速度和安全性。

　　后臺是什么樣子？

　　Slack 的開發環境是我們的應用程序在遠程服務器（準確地說是 Amazon EC2 實例）上的副本。這些實例運行 Slack 應用程序及其所依賴的許多服務。

　　每個開發環境都有自己的 Slack 子域，我們可以在瀏覽器中查看我們的更改。開發環境中的任何更改都不會影響實際用戶，因為它們自己有一套與生產環境隔離的基礎設施（例如數據庫）。

開發環境和生產環境是完全隔離的。（圖標來自Flaticon，由Freepik提供）

　　遠程開發 vs. 本地開發

　　在 Slack，我們是遠程開發，這意味著我們的開發環境在服務器上。另一個選項是在我們的個人電腦上進行本地開發。對于小型項目來說，本地開發非常好，因為它速度快，而且不需要聯網。然而，對于較大的項目，遠程開發環境則有顯著的優勢。

　　首先，我們不必在本地設置 Slack 應用程序。Slack 的架構非常復雜，它依賴于許多不同的服務，不用在本地設置是非常有價值的。

　　其次，如果一項更改在開發環境中有效，那么它在生產環境中也很可能有效，因為我們將開發環境配置為生產環境的鏡像。對于使用時間特別長的開發環境，可能仍然會出現某種程度的偏差，但是，出現這種偏差的可能性以及偏差的幅度，都要比在本地使用單獨的機器進行開發時小得多，本地開發經常會導致配置不一致。

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

　　隨著互聯網變得越來越快、越來越可靠，遠程開發越來越有意義。

　　如何使用開發環境？

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

　　我們首先創建一個特性分支，然后使用一個名為 slack sync-dev 的命令行工具將其追加到開發環境中。它會隨機預定一個開發環境，然后將本地更改同步到上面。這樣，我們本地編輯的任何內容在保存時都會自動傳輸到開發環境。

　　slack sync-dev只是對兩個著名的實用工具fswatch（檢測更改）和rsync（傳輸更改）的封裝。

同步到開發環境

　　如果做了任何前端更改，我們就必須使用 webpack（我們用作構建系統的一個開源工具）在本地構建它們。命令 slack run buildy:watch 構建我們的前端資產，并通過本地主機將它們提供給我們的開發環境。

　　完成后，我們可以導航到 dev575 子域。

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

　　現在，我們可以在頁面上找 Bug，調整更改，并與他人共享以供審核。

　　前端更改是由個人計算機構建并提供。如果想讓其他人在我們關機后還能夠看到這些更改，我們就必須生成一個靜態構建，在開發環境中構建前端資產，而不是在本機。

　　為什么在本機構建前端？

　　2017 年，當首次引入 webpack 時，我們是在開發環境中遠程構建前端更改。當有人更改了前端并同步后，開發環境就會自動重新構建前端資產。

　　然而，隨著代碼庫的增長，webpack 變得越來越消耗資源。構建會消耗整個實例的內存。當時，多個開發人員在同一個實例上工作，他們經常被打斷。因此，我們將 webpack 轉移到了本地機器上。

　　現在，每個實例只有一個開發環境，而有了更高級的實例，就完全有可能將 webpack 移回我們的開發環境，開發人員將獲得更流暢的體驗。但目前，系統運行速度很快，而且可擴展，所以我們覺得沒必要去修復沒壞的東西。

　　改進命令行工具

　　我們討論一下命令行工具。上文已經介紹了一些，比如 slack sync-dev。Slack 離不開這些工具，因為它們讓開發更快、更簡單。

　　早期，在還沒有 slack sync-dev 的時候，我們不得不手動地將我們的更改復制到開發環境中，這很耗時，而且容易出錯?，F在，我們有 60 多個命令行工具，這簡化了許多這樣的日常任務。

　　其他的例子包括 slack bo-me（它在當前開發環境中創建一個 bot 用戶）以及 slack tail-dev（它跟蹤當前開發環境中的遠程日志）。如果你想進一步了解我們的開發工具，請查看我們 2016 年發表的博文。

　　擴展我們的開發環境

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

　　不過，這一增長趨勢并沒有持續下去，事實上，2020 年就完全逆轉了。在討論原因之前，讓我們先看看另一個隨時間變化的有趣指標：每個 EC2 實例上開發環境的數量。

　　隨著時間的推移，數值在下降，因為我們想將開發環境彼此隔離開來。當多個環境共享同一個實例時，如果有一個開發人員在其中一個環境上運行一個內存密集型進程，就會降低其他所有環境的運行速度。

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

　　為了解決這些問題，我們創建了一個按需提供開發實例的新系統，逆轉了第一個圖表中所顯示的增長趨勢。我們按需提供新實例，而不是保持數百個實例同時運行。一旦開發人員完成了測試，他們使用的實例將被自動刪除。有了這個系統，我們就可以更有效地使用開發環境。我們將在下一篇文章中深入討論這些擴展方面的演進，請繼續關注！

　　作者介紹：

　　Michael是 Slack 平臺團隊的一名軟件工程師。他已在 Slack 工作了將近 3 年。期間，他參與了各種各樣的項目，包括面向用戶的功能、API 基礎設施和擴展實驗。

　　英文原文：Development Environments at Slack

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。