在典型的編程中，幾乎失去平衡的方面之一是對最終用戶體驗結果的忽視。我們都花很多精力去編寫優秀而有用的程序；但是，把這些程序交付到用戶手中這件事卻是我們開發者做得最糟糕的標志性事情之一。在這個月中，Cameron 將講解解決這個問題的技術性辦法。 您的組織投資了很多 — 可能是為期一周或十五個月的工程時間或 385，000 美元的許可費 — 到某個軟件上。這個軟件在您設置的演示主機上運行得非常不錯。然而，當最終用戶設法從中獲益時，獲得的卻只有沮喪：惹人心煩的不正確安裝，神秘復雜的配置，不可再現的信息讀取失敗，或者程序根本就什麼也不做。 有些事錯誤得非常嚴重，而且非常離譜。我給計算技術的這一方面貼上的標簽是“部署”。當某個軟件在您的屏幕上時，您的老板或客戶說，“我喜歡這個東西！”，從此時一直到最終用戶打電話或寫信來說，“這正是我們一直在等待的東西。”，這期間發生的所有事情都是部署。 從原則上說，那只是一個簡短的步驟。部署不是一個像算法理論、網絡負載分析或者甚至是需求獲得那樣深奧難懂的問題。然而，作為一個產業，我們總的來說對部署重視不夠，處理不當，投資也不足。其後果不難想像：軟件開發中一些最嚴重的浪費都與部署有關。本月的“服務器診所”將為您講解如何能在您自己的工作中做得更好。
具體示例 首先，我們來看一個示例，以對部署涉及到什麼有個一般的“感覺”。假設您曾與某化學專業的同事合作開發一個有趣的水泥養護計算機仿真程序。您們兩個對該程序在您們的開發服務器上的表現頗引以為豪 — 程序能處理各種大氣情勢以及地面狀況等等。真是棒極了！ 但是，與其他工程師合作共事並不像您預想的那麼順利。所安裝的 C 和 Qt 運行時庫的一點點改動就會產生莫名其妙的結果，甚至會導致進程異常終止。有些對等機在 AXP 上的 Linux 可以運行，但在 Intel 上的 Linux 卻不行。有一位研究人員，他為之工作的組織要求所有的安裝都必須裝在 /var 目錄下，而 /usr/local 下則不可以裝任何東西。 好消息是，該工作組的每位成員都有了 Linux，不需要坐在位於瑞典和南非的鍵盤前就可以完成安裝。壞消息是，即使有了遠程登錄，每次交付程序所花費的時間平均下來還是要半個小時以上。要不了多久，您安裝程序所花費的時間加起來就會超過第一次實現程序時所用去的時間。 真正令其糟糕的是這種情況很具有典型性。信息技術（IT）文化已經約定俗成地容忍了這類災難。我們承認安裝是脆弱和易出錯的。 但是，您可以不接受它。這裡是使事情有所不同的辦法：
部署的原則 不要從購買安裝產品入手。有幾個事項都很有價值，其中理解更具有決定性意義。 需要理解的最重要的事項是，與計算技術的許多方面一樣，良好的部署也始於良好的分析。對於上面所述的示例，您若想要取得成功，就得要求自己寫出明確的需求，例如： 應用程序應可以作為一個單文件映象進行傳送和安裝。 應用程序應可以在任何配置有 glibc 2.2-2.2.5 的 Intel Linux 主機上運行。 應用程序應不要求裝有其它的庫（如 Qt）。 應用程序在第一次注冊期間必須具有 IP 連接。 當應用程序檢測到它的某項要求未得到滿足時，它會寫一條明確的診斷信息到控制台，然後得體地退出。 還有其它…… 為貫徹執行這些編寫要求，我喜歡從第一天起就讓安裝過程保持是可執行的。請考慮一下著名的極端編程者（Extreme Programmer）（要了解背景情況，請參閱參考資料），他們須在實現要被測試的應用程序之前編寫測試。同理，我會在那些測試之前至少編寫一些簡單的安裝。通過使安裝具有可回歸性，我就可以確信，在任何時候，我都可以可靠地以低廉的代價把我的開發的任何版本安裝到某個客戶的機器上。 我屬於同意這一點的少數派。許多組織都把大量投資投到了前端分析、框圖繪制、培訓以及開發的其它方面上，卻只在開發周期的後期才偶而讓程序員們去探察有助於部署的編譯器、交叉編譯器、許可證管理器以及其它工具。就我所知，還沒有人對每種辦法的可取之處進行過正式研究。而本專欄所能提供的只是澄清各種看法。我自己的工作證明了從一開始就把部署計劃考慮進去是有可能的。我的經驗使我確信，這是一種更好的工作方式。讓您的選擇成為一個明確的選擇吧，而不只是保持過去的做法的結果。
部署的重要觀念 除一般的管理原則 — 計劃、使事情明晰、對比成本和收益 — 之外，部署還涉及幾個您要學習的特定觀念：
沒有安裝程序能夠解決所有問題 部署可能涉及把軟件交付給 6 位移動技術專家，或者是安裝到位於一幢建築物內的 1，800 台台式機上，或者是交付給遍布於全世界的 300 個最終用戶。部署的對象可能是一組完全相同的硬件，或者也可能每台主機都有所不同。 不要指望哪個部署系統能很好的適用於所有這些場合。但也別灰心；盡管問題可能比您一眼看上去要嚴重，但基本上是肯定可以解決的。在這一點的考慮上，存在的一個危險是，組織輕易就會試圖通過准備好一個簡單的答案來解決這些問題，有時甚至連問題都還不知道。 有時，熱心人會說使用 Java，或者某種特殊的動態鏈接模式，或者軟件倉庫（software depot），或者配置管理產品，或者其它技術竅門均應該能解決部署問題。然而，這些辦法沒有一個是放之四海而皆准的。它們的成本和收益各半。請考慮一下共享對象庫。假設您的一台服務器上有 79 個全都有缺陷的應用程序，原因在於它們都依賴於發生故障的系統 printf()。有了動態鏈接，您就可以只更新一個 C 運行時庫，然後修正所有 79 個應用程序的共同問題。不過，這個方案要求所有應用程序使用庫的同一個版本，或者至少有一些新的過程來管理庫的版本。更糟的是，您的針對最終用戶的安裝過程必須既管理應用程序可執行文件，又管理任何它所依賴的共享對象庫。這恰好導致了 Microsoft Windows 管理員們稱之為“DLL 地獄”的一類組合式復雜性。
更新問題 在您認真仔細地把您的部署要求寫下來的時候，對更新問題要給予特別的關注。當更新一台安裝了您的軟件的主機時，將會發生什麼？如果現有的安裝來自於某個不同的版本，將會如何？單台主機的不同用戶可以看到不同版本嗎，還是整台機器上應該只有一個版本？
程序、數據和配置 考慮部署和安裝的一種富有成效的方法是從以下三個方面進行考察： 程序 數據 配置 假設您負責的是一個文字處理器應用程序。要稱心如意地安裝這個應用程序，您需要 將程序裝到合適的地方 保護用戶已經編制好的任何文檔 識別出環境首選項、字體、宏、顯示顏色以及用戶所創建的其它交叉文檔約定 安裝產品極少能做到“取出即可用”，原因之一是上述三個方面的每一個很可能有一個不同的更新生命周期。 不管這聽起來有多麼苛刻，還是請您記住，在開發的早期就找出這些要求要明智得多。
利用文件系統 面對這麼多的困難，您如何取得成功的結果呢？首先，請讓事情保持簡單。對於大多數的開發，我都放棄了復雜的組 ID、信號處理以及其它一些次要的事情；許多站點並未合理管理這些事情，而試圖去“糾正”其模式，如此便只會加重您自己以及您的客戶的挫折感。 非常適合於部署的一種模型是文件系統模型。請利用它。盡管有缺陷，但文件系統的用戶界面至少是多數最終用戶所熟悉的。我強烈建議安裝單文件的可執行文件（無附加動態庫之類）或者那些將其本身解包至單個目錄下的映像，其原因就在於此。這些簡單的方案使用戶有可能知道究竟是否安裝了某個產品、如何卸載該產品以及如何對其進行備份。 采用簡單的面向文件系統的安裝這種傾向的存在使得我最欣賞的部署技術 — 商業安裝程序（commercial installer）、自解包二進制隨附軟件、“腳本化文檔（scripted document）”以及“虛擬文件系統（virtual file system（VFS））”— 自然也會得到一點偏愛。腳本化文檔和 VFS 是宏大的主題，值得開辟它們自己的專欄。現在我將給出簡要的定義，提供一些在線參考資料，您可以從中讀到更多信息，將來的“服務器診所”專欄將提供關於這些話題的更詳細信息，到時也歡迎您回來。
腳本化文檔 “腳本化文檔”是獨立顧問 Jean-Claude Wippler 給他發明的一種文件格式所貼的標簽。他分兩部分提供應用程序：一個與應用程序無關的、特定於平台的可執行文件，另一個是與平台無關的、特定於應用程序的“腳本化文檔”，這個腳本化文檔隨附有可執行代碼、用戶數據以及一些持久性方法。這些腳本化文檔用起來很方便，至少對於我所碰到的許多部署情形是如此。就像文件系統中的普通文件一樣，它們可以被復制 — 甚至復制到操作系統上，除了 Linux！— 重命名、刪除、備份，以及進行其它操作。同時，這些文檔包括了較為傳統的應用程序分布在安裝文件或目錄中的所有信息。 在“服務器診所”回來討論這個主題之前，您可以在下面的參考資料中讀到一些我的關於腳本化文檔的摘記。同時，請記住，部署是一件要做正確的很重要的事，而要把這件事做正確，第一步就是給要求編寫文檔。
