一位Smalltalk 程序員眼中的開發和部署

多年前，我曾是一名 Smalltalk 程序員，這種經驗讓我以一種不一樣的視角來觀察編程的世界，例如，須要花時間來適應源代碼應該存儲在文本文件中的這種作法。

咱們做爲程序員一般會區分「開發」和「部署」，特別是咱們在開發的地方所使用的工具不一樣於咱們在以後部署軟件時的地點和工具時。而在 Smalltalk 世界裏，沒有這樣的區別。

Smalltalk 構建於虛擬機包含了你的開發環境（IDE、調試器、文本編輯器、版本控制等）的思路之上，若是你須要修改任何一處代碼，你得修改內存中運行副本。若是須要的話，你能夠爲運行中的機器作個快照；若是你想分發你的代碼，你能夠發送一個運行中的機器的鏡像副本（包括 IDE、調試器、文本編輯器、版本控制等）給用戶。這就是上世紀 90 年代軟件開發的方式（對咱們中的一些人來講）。

現在，部署環境與開發環境有了很大的不一樣。起初，你不要指望那裏（指部署環境）有任何開發工具。一旦部署，就沒有版本控制、沒有調試、沒有開發環境。有的是記錄和監視，這些在咱們的開發環境中都沒有，而有一個「構建管道」，它將咱們的軟件從開發形式轉換爲部署形式。做爲一個例證，Docker 容器則試圖從新找回上世紀 90 年代 Smalltalk 程序員部署體驗的那種簡單性，而避免一樣的開發體驗。

我想若是 Smalltalk 世界是我惟一的編程方面的體驗，讓我沒法區分開發和部署環境，我可能會偶爾回顧一下它。可是在我成爲一名 Smalltalk 程序員以前，我仍是一位 APL 程序員，這也是一個可修改的虛擬機鏡像的世界，其中開發和部署是沒法區分的。所以，我相信，在當前的時代，人們編輯單獨的源代碼文件，而後運行構建管道以建立在編輯代碼時尚不存在的部署做品，而後將這些做品部署給用戶。咱們已經以某種方式將這種反模式的軟件開發制度化，而不斷髮展的軟件環境的需求正在迫使咱們找回到上世紀 90 年代的更有效的技術方法。所以纔會有 Docker 的成功，因此，我須要提出個人建議。

我有兩個建議：咱們在運行時系統中實現（並使用）版本控制，以及，咱們經過更改運行中的系統來開發軟件，而不是用新的運行系統替換它們。這兩個想法是相關的。爲了安全地更改正在運行的系統，咱們須要一些版本控制功能來支持「撤消」功能。也許公平地說，我只提出了一個建議。讓我舉例來講明。

讓咱們開始假設一個靜態網站。你要修改一些 HTML 文件。你應該如何工做？若是你像大多數開發者同樣，你會有兩個，也許三個網站 - 一個用於開發，一個用於 QA（或者預發佈），一個用於生產。你將直接編輯開發實例中的文件。準備就緒後，你將把你的修改「部署」到預發佈實例。在用戶驗收測試以後，你將再次部署，此次是生產環境。

使用 Occam 的 Razor，讓咱們能夠避免沒必要要地建立實例。咱們須要多少臺機器？咱們可使用一臺電腦。咱們須要多少臺 web 服務器？咱們可使用具備多個虛擬主機的單臺 web 服務器。若是不使用多個虛擬主機的話，咱們能夠只使用單個虛擬主機嗎？那麼咱們就須要多個目錄，並須要使用 URL 的頂級路徑來區分不一樣的版本，而不是虛擬主機名。可是爲何咱們須要多個目錄？由於 web 服務器將從文件系統中提供靜態文件。咱們的問題是，目錄有三個不一樣的版本，咱們的解決方案是建立目錄的三個不一樣的副本。這不是正是 Subversion 和 Git 這樣的版本控制系統解決的問題嗎？製做目錄的多個副本以存儲多個版本的策略回到了版本控制 CVS 以前的日子。爲何不使用好比說一個空的的 Git 倉庫來存儲文件呢？要這樣作，web 服務器將須要可以從 git 倉庫讀取文件。

這將是一個支持版本控制的運行時系統。

使用這樣的 web 服務器，使用的版本能夠由 cookie 來標識。這樣，任何人均可以推送到倉庫，用戶將繼續看到他們發起會話時所分配的版本。版本控制系統有不可改變的提交； 一旦會話開始，開發人員能夠在不影響正在運行的用戶的狀況下快速推送更改。開發人員能夠重置其會話以跟蹤他們的新提交，所以開發人員或測試人員就可能如普通用戶同樣查看在同臺服務器上同一個 URL 上正在開發或正在測試的版本。做爲偶然的反作用，A/B 測試僅僅是將不一樣的用戶分配給不一樣的提交的狀況。全部用於管理多個版本的 git 設施均可以在運行環境中發揮做用。固然，git reset 爲咱們提供了前面提到的「撤銷」功能。

爲何不是每一個人都這樣作？

一種可能性是，諸如版本控制系統的工具沒有被設計爲在生產環境中使用。例如，給某人推送到測試分支而不是生產分支的許但是不可能的。對這個方案最多見的反對是，若是發現了一個漏洞，你會想要將某些提交標記爲不可訪問。這將是另外一種更細粒度的權限的狀況；開發人員將具備對全部提交的讀取權限，但外部用戶不會。咱們可能須要對現有工具進行一些額外的改造以支持這種模式，可是這些功能很容易理解，並已被設計到其餘軟件中。例如，Linux （或 PostgreSQL）實現了對不一樣用戶的細粒度權限的想法。

隨着雲環境變得愈來愈普及，這些想法變得更加相關：雲老是在運行。例如，咱們能夠看到，AWS 中等價的 「文件系統」（S3）實現了版本控制，因此你可能有一個不一樣的想法，使用一臺 web 服務器提供來自 S3 的資源文件，並根據會話信息選擇不一樣版本的資源文件。重要的並非哪一個實現是最好的，而是支持這種運行時版本控制的願景。

部署的軟件環境應該是「版本感知」的原則，應該擴展到除了服務靜態文件的 web 服務器以外的其餘工具。在未來的文章中，我將介紹版本庫，數據庫和應用程序服務器的方法。

做者簡介：

Robert M. Lefkowitz - Robert（即 r0ml）是一個喜歡複雜編程語言的編程語言愛好者。 他是一個提升清晰度、提升可靠性和最大限度地簡化的編程技術收藏家。他經過讓計算機更加容易得到來使它普及化。他常常演講中世紀晚期和早期文藝復興對編程藝術的影響。

via: https://opensource.com/article/17/1/difference-between-development-deployment

做者：Robert M. Lefkowitz 譯者：geekpi 校對：Bestony

本文由 LCTT 原創編譯，Linux中國 榮譽推出

原文來自：https://linux.cn/article-8539-1.html

本文地址：https://www.linuxprobe.com/old-geek.html編輯員：郭建鵬，審覈員：逄增寶