共用方式為

應用程式生命週期管理：從開發到生產環境

  • 發行項

演講者：Jason Lee

本主題說明一家虛構的公司如何透過測試、預備和生產環境來管理 ASP.NET Web 應用程式的部署，作為持續開發過程的一部分。 在整個主題中，提供了有關如何執行特定任務的更多資訊和演練的連結。

本主題旨在為企業中 Web 部署的一系列教學課程提供進階概述。 如果您對這裡描述的某些概念不熟悉，不用擔心，接下來的教學課程將提供這些任務和技術的詳細資訊。

注意

為了簡單起見，本主題不討論將更新資料庫作為部署程序的一部分。 但是，對資料庫功能進行增量更新是許多企業部署方案的要求，您可以在本教學課程系列後面找到有關如何完成此操作的指南。 有關更多資訊，請參閱「部署資料庫專案」。

概觀

此處所示的部署流程是基於「企業 Web 部署：情境概述」中所述的 Fabrikam, Inc. 部署情境。 在學習本主題之前，應該先閱讀情境概述。 基本上，本情境主要探討一個組織如何在典型企業環境中的各個階段，管理一個相對複雜的 Web 應用程式 (連絡人管理員解決方案) 的部署。

從高層次來看，連絡人管理員解決方案在開發和部署過程中經歷以下幾個階段：

  1. 開發人員將部分程式碼簽入 Team Foundation Server (TFS) 2010。
  2. TFS 建立程式碼並執行與團隊專案相關的任何單元測試。
  3. TFS 將解決方案部署到測試環境。
  4. 開發團隊在測試環境中驗證和驗證解決方案。
  5. 預備環境管理員對預備環境執行「假設狀況」部署，以確定部署是否會導致任何問題。
  6. 預備環境管理員對預備環境執行即時部署。
  7. 此解決方案在預備環境中經過使用者驗收測試。
  8. 手動將Web部署包匯入到生產環境中。

這些階段構成持續開發週期的一部分。

這些階段構成持續開發週期的一部分。

實際上，這個程序比這稍微複雜一些，當我們更詳細地了解每個階段時您就會看到。 Fabrikam, Inc. 對每個目標環境使用不同的部署方法。

Fabrikam, Inc. 對每個目標環境使用不同的部署方法。

本主題的其餘部分將研究此部署生命週期的這些關鍵階段：

  • 必要條件：在部署部署邏輯之前，您需要如何設定伺服器基礎結構。
  • 初步開發和部署：首次部署解決方案之前需要執行的操作。
  • 部署到測試環境：當開發人員簽入新程式碼時，如何自動封裝內容並將其部署到測試環境。
  • 部署到預備環境：如何將特定建置部署到預備環境以及如何執行「假設狀況」部署以確保部署不會導致任何問題。
  • 部署到生產環境：當網路基礎結構阻止遠端部署時，如何將 Web 套件匯入生產環境。

必要條件

任何部署情境中的首要任務是確保您的伺服器基礎結構符合部署工具和技術的要求。 在本例中，Fabrikam, Inc. 的伺服器基礎結構設定如下：

初步開發和部署

在 Fabrikam, Inc. 開發團隊首次部署連絡人管理員解決方案之前，需要執行下列任務：

  • 在 TFS 中建立一個新的團隊專案。
  • 建立包含部署邏輯的 Microsoft Build 引擎 (MSBuild) 專案檔案。
  • 建立觸發部署程序的 TFS 建置定義。

建立一個新的團隊項目

建立部署邏輯

Matt Hink 使用「了解專案檔案」中所述的分割專案檔案方法，來建立各種自訂 MSBuild 專案檔案。 Matt 會建立：

  • 名為 Publish.proj 的專案檔案，用於執行部署流程。 此檔案包含 MSBuild 目標，用於在解決方案中產生專案、建立 Web 套件並將套件部署到目標伺服器環境。
  • 名為 Env-Dev.proj 和 Env-Stage.proj 的環境專屬專案檔案。 它們分別包含特定於測試環境和預備環境的設定，例如連接字串、服務端點以及將接收 Web 套件的遠端服務的詳細資訊。 有關為特定目標環境選擇正確設定的指南，請參閱「設定目標環境的部署屬性」。

若要執行部署，使用者使用 MSBuild 或 Team Build 執行 Publish.proj 檔案，並指定相關環境特定專案檔案 (Env-Dev.proj 或 Env-Stage.proj) 的位置作為命令列參數。 然後，Publish.proj 檔案匯入特定於環境的專案檔案，以為每個目標環境建立一套完整的發佈指令。

注意

這些自訂專案檔案的工作方式獨立於您用來呼叫 MSBuild 的機制。 例如，您可以直接使用 MSBuild 命令列，如「了解專案檔案」中所述。 您可以從命令文件執行專案檔案，如「建立和執行部署命令檔」所述。 或者，您可以從 TFS 中的建置定義執行專案檔案，如「建立支援部署的建置定義」中所述。
在每種情況下，最終結果都是相同的，MSBuild 會執行合併的專案檔案，並將解決方案部署到目標環境。 這為您觸發發佈流程的方式提供了極大的靈活性。

建立自訂專案檔案後，Matt 將它們新增至解決方案資料夾並將它們簽入原始程式碼管理。

建立組建定義

作為最後的準備任務，Matt 和 Rob 共同為新團隊專案建立三個建置定義：

  • DeployToTest。 這將建置連絡人管理員解決方案，並在每次簽入時部署到測試環境。
  • DeployToStaging。 當開發人員對建置進行排隊時，這會將資源從指定的先前建置部署到預備環境。
  • DeployToStaging-WhatIf。 當開發人員對建置進行排隊時，這會執行到預備環境的「假設狀況」部署。

以下各節提供了有關每個建置定義的更多詳細資訊。

部署測試環境

Fabrikam, Inc. 的開發團隊會維護測試環境以進行各種軟體測試活動，例如驗證和確認、可用性測試、相容性測試以及預備或探索性測試。

開發團隊在 TFS 中建立了一個名為 DeployToTest 的建置定義。 此建置定義使用持續整合觸發程序，這表示每次 Fabrikam, Inc. 開發團隊的成員執行簽入時都會執行建置程序。 當觸發建置時，建置定義將：

  • 建置 ContactManager.sln 解決方案。 這反過來又建構了解決方案中的每個項目。
  • 執行解決方案資料夾結構中的任何單元測試 (如果解決方案建置成功)。
  • 執行控制部署程序的自訂專案檔案 (如果解決方案成功建置並通過任何單元測試)。

最終結果是，如果解決方案成功建置並通過單元測試，則 Web 套件和任何其他部署資源將部署到測試環境。

最終結果是，如果解決方案成功建置並通過單元測試，則 Web 套件和任何其他部署資源將部署到測試環境。

部署程序如何進行？

DeployToTest 產生定義為 MSBuild 提供以下參數：

/p:DeployOnBuild=true;DeployTarget=package;TargetEnvPropsFile=[path]\Env-Dev.proj

當 Team Build 在解決方案中產生專案時，將使用 DeployOnBuild=True 和 DeployTarget=package 屬性。 當專案是 Web 應用程式專案時，這些屬性指示 MSBuild 為該專案建立 Web 部署套件。 TargetEnvPropsFile 屬性會告訴 Publish.proj 檔案在哪裡可以找到要匯入的環境專屬專案檔案。

注意

有關如何建立此類建置定義的詳細演練，請參閱「建立支援部署的建置定義」。

Publish.proj 檔案會包含建置解決方案中每個專案的目標。 但是，它還包括條件邏輯，如果您在 Team Build 中執行文件，則會跳過這些建置目標。 這可讓您利用 Team Build 提供的附加建置功能，例如執行單元測試的能力。 如果解決方案建置或單元測試失敗，則不會執行 Publish.proj 檔案，也不會部署應用程式。

條件邏輯是透過評估 BuildingInTeamBuild 屬性來完成的。 這是一個 MSBuild 屬性，當您使用 Team Build 產生專案時，該屬性會自動設為 True。

部署到預備環境

當建置滿足測試環境中開發團隊的所有要求時，團隊可能希望將相同的建置部署到預備環境。 預備環境通常設定為盡可能匹配生產或「即時」環境的特徵，例如，在伺服器規格、作業系統和軟體以及網路設定方面。 預備環境通常用於負載測試、使用者驗收測試和更廣泛的內部審查。 建置直接從建置伺服器部署到預備環境。

建置直接從建置伺服器部署到預備環境。

用於將解決方案部署到預備環境的建置定義 DeployToStaging-WhatIf 和 DeployToStaging 具有以下共同特徵：

  • 他們實際上並沒有建造任何東西。 當 Rob 將解決方案部署到預備環境時，他希望部署已在測試環境中經過驗證和驗證的特定現有建置。 建置定義只需要執行控制部署程序的自訂專案檔案。
  • 當 Rob 觸發建置時，他使用建置參數來指定哪個建置包含他想要從建置伺服器部署的資源。
  • 建置定義不會自動觸發。 當 Rob 想要將解決方案部署到預備環境時，他會手動對建置進行排隊。

這是部署到預備環境的高階流程：

  1. 預備環境管理員 Rob Walters 使用 DeployToStaging-WhatIf 建置定義對建置進行排隊。 Rob 使用建置定義參數來指定他想要部署的建置。
  2. DeployToStaging-WhatIf 建置定義以「假設狀況」模式執行自訂專案檔。 這會產生記錄檔，就像 Rob 正在執行即時部署一樣，但它實際上不會對目標環境進行任何更改。
  3. Rob 會檢查記錄檔以確定部署對預備環境的影響。 特別是，Rob 希望檢查將新增哪些內容、將更新哪些內容以及將刪除哪些內容。
  4. 如果 Rob 確信部署不會對現有資源或資料進行任何不必要的更改，他會使用 DeployToStaging 建置定義對建置進行排隊。
  5. DeployToStaging 建置定義執行自訂專案檔。 它們將部署資源發佈到預備環境中的主 Web 伺服器。
  6. Web Farm Framework (WFF) 控制器同步預備環境中的 Web 伺服器。 這使得該應用程式可以在伺服器陣列中的所有 Web 伺服器上使用。

部署程序如何進行？

DeployToStaging 產生定義為 MSBuild 提供以下參數：

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;OutputRoot=[path to build folder]

TargetEnvPropsFile 屬性會告訴 Publish.proj 檔案在哪裡可以找到要匯入的環境專屬專案檔案。 OutputRoot 屬性會覆寫內建值，並指示包含要部署的資源的建置資料夾的位置。 當 Rob 對建置進行排隊時，他使用「參數」標籤為 OutputRoot 屬性提供更新的值。

當 Rob 對建置進行排隊時，他使用「參數」標籤為 OutputRoot 屬性提供更新的值。

注意

有關如何建立此類建置定義的更多資訊，請參閱「部署特定建置」。

DeployToStaging-WhatIf 建置定義包含與 DeployToStaging 建置定義相同的部署邏輯。 但是，它包含附加參數 WhatIf=True：

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;
   OutputRoot=[path to build folder];
   WhatIf=true

在 Publish.proj 檔案中，WhatIf 屬性指示所有部署資源都應以「假設狀況」模式發佈。 換句話說，記錄檔的產生就像部署已經進行一樣，但目標環境中實際上沒有任何變更。 這使您可以在實際進行任何更改之前評估擬議部署的影響，特別是將新增哪些內容、將更新哪些內容以及將刪除哪些內容。

注意

有關如何設定「假設狀況」部署的更多資訊，請參閱「執行「假設狀況」部署」。

將應用程式部署到預備環境中的主 Web 伺服器後，WFF 將自動在伺服器叢集中的所有伺服器之間同步應用程式。

注意

有關設定 WFF 以同步 Web 伺服器的詳細資訊，請參閱「使用 Web Farm Framework 建立伺服器陣列」。

部署到生產環境

當建置在預備環境中獲得核准後，Fabrikam, Inc. 團隊就可以將應用程式發佈到生產環境。 生產環境是應用程式「上線」並到達終端使用者目標受眾的地方。

生產環境位於面向網際網路的外圍網路。 這與包含建置伺服器的內部網路隔離。 生產環境管理員 Lisa Andrews 必須手動從產生伺服器複製 Web 部署套件並將其匯入主生產 Web 伺服器上的 IIS。

生產環境管理員必須手動從建置伺服器複製 Web 部署套件並將其匯入到主生產 Web 伺服器上的 IIS 中。

這是部署到生產環境的高階流程：

  1. 開發團隊建議 Lisa 建置已準備好部署到生產環境。 該團隊向 Lisa 建議 Web 部署套件在建置伺服器上放置資料夾中的位置。
  2. Lisa 從建置伺服器收集 Web 套件並將其複製到生產環境中的主 Web 伺服器。
  3. Lisa 使用 IIS 管理員在主 Web 伺服器上匯入和發佈 Web 套件。
  4. WFF 控制器同步生產環境中的 Web 伺服器。 這使得該應用程式可以在伺服器陣列中的所有 Web 伺服器上使用。

部署程序如何進行？

IIS 管理員包括匯入應用程式套件精靈，可輕鬆地將 Web 套件發佈到 IIS 網站。 有關如何執行此程序的演練，請參閱「手動安裝 Web 套件」。

結論

本主題提供了典型企業級 Web 應用程式的部署生命週期說明。

本主題構成一系列教學課程的一部分，這些教學課程提供有關 Web 應用程式部署各個方面的指導。 實際上，部署程序的每個階段都有許多額外的任務和注意事項，不可能在一次演練中涵蓋所有這些任務和注意事項。 有關更多資訊，請參閱以下教學課程：

上一筆