在本文中，開發環境是指可以在部署之前測試代碼更改的沙箱，不是Eclipse或Microsoft Visual Studio這樣的集成開發環境（IDE）。
本文最初發佈於Slack官方博客，由InfoQ中文站翻譯並分享。
對我來說，開發環境一直是個謎。儘管我在Slack的第一天就瞭解了它們，並在過去三年幾乎每天都在使用它們，但我從未真正地理解它們。
半年前，我定了一個目標，要全面瞭解開發環境。我與Slack一些最資深的工程師進行了交流，研究了無數文檔，篩選了多年的Slack對話。從中，我發現了一個關於Slack開發環境隨時間演進的有趣旅程。
爲什麼需要開發環境？
開發環境是我們可以自由修改的應用程序副本。它們的主要價值是讓我們可以在不影響實際用戶或不泄露真實數據的情況下測試應用程序更改。
開發環境使我們能夠快速迭代，因爲在上面測試更改非常快也非常簡單。通過它，我們可以很容易地與他人共享更改以供審覈。
總之，開發環境極大提高了開發速度和安全性。
後臺是什麼樣子？
Slack的開發環境是我們的應用程序在遠程服務器（準確地說是Amazon EC2實例）上的副本。這些實例運行Slack應用程序及其所依賴的許多服務。
每個開發環境都有自己的Slack子域，我們可以在瀏覽器中查看我們的更改。開發環境中的任何更改都不會影響實際用戶，因爲它們自己有一套與生產環境隔離的基礎設施（例如數據庫）。
遠程開發 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的時候，我們不得不手動地將我們的更改複製到開發環境中，這很耗時，而且容易出錯。現在，我們有60多個命令行工具，這簡化了許多這樣的日常任務。
其他的例子包括slack bo-me（它在當前開發環境中創建一個bot用戶）以及slack tail-dev（它跟蹤當前開發環境中的遠程日誌）。如果你想進一步瞭解我們的開發工具，請查看我們2016年發表的博文。
擴展我們的開發環境
2014年的時候，我們只有一個開發環境供所有人使用。如果有人破壞了這個環境，其他人就無法測試他們的更改了。這在當時並不是什麼大問題，但隨着Slack的發展，我們不得不增加開發環境。到2019年底，我們已經維護了550個開發環境，足夠每個Slack工程師都連接到一個不同的開發環境。
不過，這一增長趨勢並沒有持續下去，事實上，2020年就完全逆轉了。在討論原因之前，讓我們先看看另一個隨時間變化的有趣指標：每個EC2實例上開發環境的數量。
隨着時間的推移，數值在下降，因爲我們想將開發環境彼此隔離開來。當多個環境共享同一個實例時，如果有一個開發人員在其中一個環境上運行一個內存密集型進程，就會降低其他所有環境的運行速度。
這是一個折衷——每個實例上的開發環境數少了，就意味着我們需要購買更多的EC2實例。此外，這些實例是靜態託管的，因此，我們需要花大量的工程時間來提供新的實例以及刪除損壞的實例。更糟糕的是，長期運行的實例會隨着時間的推移而變得混亂，而其行爲將不再可靠。
爲了解決這些問題，我們創建了一個按需提供開發實例的新系統，逆轉了第一個圖表中所顯示的增長趨勢。我們按需提供新實例，而不是保持數百個實例同時運行。一旦開發人員完成了測試，他們使用的實例將被自動刪除。有了這個系統，我們就可以更有效地使用開發環境。我們將在下一篇文章中深入討論這些擴展方面的演進，請繼續關注！
作者介紹：
Michael是Slack平臺團隊的一名軟件工程師。他已在Slack工作了將近3年。期間，他參與了各種各樣的項目，包括面向用戶的功能、API基礎設施和擴展實驗。