2014-04-11 96 views
7

我正在嘗試爲我們的一些ASP.NET應用程序設置部署鏈。首選的工具是Web Deploy(msdeploy) - 目前。不幸的是我被困在一個問題上。如何使用web部署(msdeploy)升級(合併)web.config?

鏈的高級概述是這樣的:

  1. 的Web開發者創建在SVN的代碼,並檢查它;
  2. Buildserver看到更新並構建網站的msdeploy .zip包;
  3. .zip包會自動放入我們的安裝程序併發送給各種客戶端;
  4. 客戶端在其服務器上運行安裝程序(-s);
  5. 安裝程序在內部使用msdeploy來部署.zip軟件包並創建新網站或升級現有網站。

Msdeploy可以很容易地部署一個新的實例,但我很難理解如何執行「升級」安裝。主要問題是web.config文件。每個客戶肯定會在那裏進行一些定製以適合他們的特定環境。安裝程序本身提供了在首次安裝時設置一些更重要的參數(由msdeploy的參數機制實現),但它們可以手動完成其他操作。另一方面,我們的開發者偶爾會對web.config進行更改,添加一些新設置或刪除過時的設置。所以我不能只告訴msdeploy完全忽略這個文件。我需要某種先進的XML修改機制。它可能是開發者維護的腳本,但它只需要在升級時運行,而不是新安裝。

我不知道如何做到這一點。

除此之外,有時還有一些完全奇怪的升級邏輯。例如,應用程序隨附我們的公司徽標,但有些客戶已替換該.png文件以顯示其自己的徽標。最近我們需要更新徽標 - 但只適用於那些沒有用自己的徽標取代它的客戶。

同樣,可能有一些緩存文件夾可能需要在某些升級時清理,而在其他升級時則不需要。或者用戶內容可能未觸及的文件夾(但在初始安裝時會附帶默認內容)。等等

您通常如何實現msdeploy包的這種雙重行爲?我真的需要爲每個應用程序創建2個不同的包嗎?

回答

2

有一些一般性的建議(不特定於msdeploy),但我希望幫助:

  • 我想你會需要提供反正幾個安裝程序:對於初始設置和每個版本 - 版本升級。

  • 我建議讓你的客戶自己合併配置文件。你可以提供它們,或者添加/更改/刪除的詳細說明,和/或包含簡化合並的實用程序。也許thisthis鏈接會給你一些指示。

  • 至於合併替換的徽標,其他客戶的定製,我認爲最好的方法是支持品牌化您的應用程序。我的意思是 - 將所有品牌細節移至新安裝程序不會觸及的地方。

  • 對於客戶做出的其他調整,他們會根據自己的風險做到這一點,所以您可以提供的唯一幫助就是包含詳細的更改列表(可能包括更改後的文件列表)以前的版本)的信息以及與像Araxis合併或類似

  • 或..你可以創建一個實用工具和工具合併源的操作方法文章它包括對安裝程序,它會嘗試做所有的棘手合併東西在客戶端的機器上。我不會推薦這種方式,因爲它需要大量的努力/資源來維護。

  • 還有一件事:您可以專注於在升級之前備份以前的客戶端副本。所以即使是客戶端也會遇到升級問題 - 總是有可能回滾。這裏唯一的一件事就是提供一個好的反饋渠道,讓你的客戶可以用它來拍攝他們的煩惱。這種反饋可以讓你找出你的客戶有什麼問題,以及如何使他們的升級過程更加舒適。從個人的經驗

4

建議:

隔離的定製

您的客戶應該有定製能力的建立和最好的辦法就是給他們提供類似的覆蓋文件。這樣你就可以安裝新的軟件包,然後在客戶的標準設置之上疊加客戶的定製。如果它是一個全新的安裝,那麼將沒有什麼可疊加的。

> top-level    -- 
    > standard files  | 
      images   | This will never be touched or changed by customer 
      settings.txt | 
         __ 
    > customer files   -- 
      images    | Customer hacks this to their heart's content 
      settings.txt_override | 
           -- 

是的,這是否意味着某種合併過程中需要發生,需要有一些腳本,這是否但是這種方法有幾個優點。

  1. 對於設置,一下子變成多餘只是發出警告,這種效果
  2. 如果客戶有自己的標識提供了覆蓋文件
  3. 的信息是明確的,以客戶指定這個能力。遠離標準文件。
  4. 如果客戶請求更多可自定義設置,則在升級期間如果它不存在覆蓋文件中,則寫入默認設置。

Vilx,在回答你的問題時,知道它是否是升級的邏輯必須包含在腳本本身中。

要在安裝之前運行升級腳本

msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -preSync:runcommand="c:\UpgradeScript.bat" 

或安裝後運行升級腳本

msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -postSync:runcommand="c:\UpgradeScript.bat" 

更多信息here

至於你怎麼知道它的升級腳本可以檢查名爲「version.txt」的文本文件,如果存在,則升級bat腳本將運行。版本包含在文本文件中。位基本,但它應該工作。

這也有給你的版本之間更優雅的合併客戶的自定義設置,你知道哪些屬性可以重寫該特定版本的功能的額外優勢。

+0

我打算搬到這個模型,是的,但即使這樣,將需要某種形式的升級腳本的。問題是 - 我如何在msdeploy中獲得升級腳本?我不明白我如何才能讓它運行腳本,當且僅當它是升級。 –

+1

+1用於隔離定製,這是處理事情的一種非常乾淨的方式。您甚至可以比這裏描述的更進一步:不是將您的客戶文件放在頂層安裝文件夾中,而是將它們放置在_outside_並且只有一個配置設置(客戶可以在安裝期間在參數文件中指定/升級)這個位置。檢查_「當且僅當它是升級」_然後就像檢查該文件夾是否存在一樣簡單(或者例如如果該文件夾內存在version.txt)。你的前/後腳本可以根據需要處理這些文件。 – Nailuj

1

我將建立在什麼上面所說的,但我會用轉換做,是誰配置什麼嚴格的文檔。現在你擁有它的方式依賴於客戶對配置的干預,這是對應用程序部署過程至關重要的配置。

創建三個配置文件區域。一個用於開發,一個用於「生產通用」版本,另一個用於客戶編輯的空模板。

  • 開發實例應該是不言而喻的。這是採用生產通用模板併爲您的開發服務器創建Web配置的轉換。 (這聽起來像你在這裏拍攝的CI型工藝)
  • 「生產通用的」轉換應設置應用了該應用程序的一個假設完美的實例。如果架構師有他的方式,這將是安裝的樣子。
  • 客戶使用客戶轉換來根據需要設置Web配置以滿足他們自己的需求。寫一些文檔,看看會發生什麼。在幫助客戶完成流程時編輯文檔。

這是你要找的東西?思考?