共用方式為

使用 Azure) 建置Real-World雲端應用程式的原始檔控制 (

  • 發行項

作者 ：Rick Anderson、 Tom Dykstra

下載修正專案 或 下載電子書

使用 Azure 電子書建置真實世界雲端應用程式是以 Scott Guthrie 開發的簡報為基礎。 其說明 13 種模式和做法，可協助您成功開發雲端的 Web 應用程式。 如需電子書的相關資訊，請參閱 第一章。

原始檔控制適用于所有雲端開發專案，而不只是小組環境。 您不會考慮編輯原始程式碼，或甚至沒有復原函式和自動備份的Word檔，而原始檔控制可在專案層級提供這些函式，讓這些函式在發生錯誤時節省更多時間。 透過雲端原始檔控制服務，您不再需要擔心複雜的設定，而且最多 5 位使用者使用Azure Repos原始檔控制。

本章的第一個部分說明要記住的三個主要最佳做法：

本章的其餘部分會在 Visual Studio、Azure 和 Azure Repos中提供這些模式的一些範例實作：

將自動化腳本視為原始程式碼

當您處理雲端專案時，您會經常變更專案，而且想要能夠快速回應客戶回報的問題。 回應快速牽涉到使用自動化腳本，如 自動化所有 專案一章所述。 您用來建立環境、部署環境、調整環境等的所有腳本都必須與應用程式原始程式碼同步。

若要讓腳本與程式碼保持同步，請將腳本儲存在您的原始檔控制系統中。 然後，如果您需要復原變更，或快速修正與開發程式碼不同的生產程式碼，您不需要浪費時間嘗試追蹤哪些設定已變更，或哪些小組成員有您需要的版本複本。 您可以確定您需要的腳本會與所需的程式碼基底同步，而且您保證所有小組成員都使用相同的腳本。 然後，無論您是需要自動測試和部署熱修正至生產環境或新功能開發，您都需要針對需要更新的程式碼設定正確的腳本。

不要簽入秘密

原始程式碼存放庫通常可供太多人存取，使其成為敏感性資料的適當安全位置，例如密碼。 如果腳本依賴密碼之類的秘密，請將這些設定參數化，使其不會儲存在原始程式碼中，並將秘密儲存在其他位置。

例如，Azure 可讓您下載包含發佈設定的檔案，以自動建立發佈設定檔。 這些檔案包含授權管理 Azure 服務的使用者名稱和密碼。 如果您使用這個方法來建立發佈設定檔，而且如果您將這些檔案簽入原始檔控制，任何可存取存放庫的任何人都可以看到這些使用者名稱和密碼。 您可以安全地將密碼儲存在發行設定檔本身，因為它已加密，而且它位於預設不包含在原始檔控制中的 .pubxml.user 檔案中。

結構來源分支以加速 DevOps 工作流程

您在存放庫中實作分支的方式會影響開發新功能並修正生產環境中問題的能力。 以下是許多中型小組使用的模式：

來源分支結構

主要分支一律符合生產環境中的程式碼。 主要下方的分支會對應到開發生命週期中的不同階段。 開發分支是您實作新功能的位置。 對於小型小組，您可能只有 主要 和開發，但我們通常建議人員在開發與 主要之間有預備分支。 在更新移至生產環境之前，您可以使用預備進行最終整合測試。

對於大型小組，每個新功能可能會有不同的分支;對於較小的小組，您可能每個人都簽入開發分支。

如果您有每個功能的分支，當功能 A 準備好時，其原始程式碼會變更為開發分支，並向下合併至其他功能分支。 此原始程式碼合併程式可能相當耗時，而且為了避免該工作仍將功能分開，有些小組會實作稱為 功能切換 的替代方式， (也稱為 功能旗標) 。 這表示所有功能的所有程式碼都位於相同的分支中，但您可以使用程式碼中的參數來啟用或停用每項功能。 例如，假設 Feature A 是修正 It 應用程式工作的新欄位，而 Feature B 會新增快取功能。 這兩個功能的程式碼都可以在開發分支中，但應用程式只會在變數設定為 true 時顯示新的欄位，而且只有在不同的變數設定為 true 時才會使用快取。 如果功能 A 尚未準備好升級，但功能 B 已就緒，您可以使用功能 A 關閉將所有程式碼升級至生產環境，並開啟功能 B。 然後，您可以完成功能 A，並在稍後升級，完全不需要原始程式碼合併。

不論您是否使用分支或切換功能，這類分支結構都可讓您以敏捷且可重複的方式將程式碼從開發流向生產環境。

此結構也可讓您快速回應客戶意見反應。 如果您需要快速修正生產環境，您也可以以敏捷的方式有效率地執行。 您可以建立 主要 或預備的分支，並在準備好將分支合併至 主要 和向下合併至開發和功能分支。

Hotfix 分支

如果沒有像這樣的分支結構與生產與開發分支區隔，生產問題可能會讓您能夠與生產修正一起升級新功能程式碼。 新功能程式碼可能無法完整測試並準備好用於生產環境，而且您可能必須執行許多工作來備份尚未就緒的變更。 或者，您可能必須延遲修正，才能測試變更並準備好進行部署。

接下來，您將會看到如何在 Visual Studio、Azure 和 Azure Repos中實作這三種模式的範例。 These are examples rather than detailed step-by-step how-to-do-it instructions; for detailed instructions that provide all of the context necessary, see the Resources section at the end of the chapter.

在 Visual Studio 中將腳本新增至原始檔控制

您可以將腳本新增至 Visual Studio 中的原始檔控制，方法是將它們納入 Visual Studio 方案資料夾中， (假設專案位於原始檔控制) 。 以下是其中一種方式。

在方案資料夾中建立腳本的資料夾， (具有 .sln 檔案的相同資料夾) 。

自動化資料夾

將腳本檔案複製到 資料夾。

自動化資料夾內容

在 Visual Studio 中，將方案資料夾新增至專案。

[新增方案資料夾] 功能表選取專案

並將腳本檔案新增至方案資料夾。

新增現有專案功能表選取專案

[加入現有項目] 對話方塊

腳本檔案現在包含在您的專案中，原始檔控制會追蹤其版本變更，以及對應的原始程式碼變更。

將敏感性資料儲存在 Azure 中

如果您在 Azure 網站中執行應用程式，避免在原始檔控制中儲存認證的方法之一，就是改為將它們儲存在 Azure 中。

例如，修正 It 應用程式會儲存在其Web.config檔案中，其中兩個連接字串將具有生產環境的密碼，以及提供您 Azure 儲存體帳戶存取權的金鑰。

<connectionStrings>
  <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItMembership.mdf;Initial Catalog=MyFixItMembership;Integrated Security=True" providerName="System.Data.SqlClient" />
  <add name="appdb" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItTasks.mdf;Initial Catalog=aspnet-MyFixItTasks;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings>
<appSettings>
  <add key="webpages:Version" value="3.0.0.0" />
  <add key="webpages:Enabled" value="false" />
  <add key="ClientValidationEnabled" value="true" />
  <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  <add key="StorageAccountName" value="fixitdemostorage" />
  <add key="StorageAccountAccessKey" value="[accesskeyvalue]" />
</appSettings>

如果您在 Web.config 檔案中放置這些設定的實際生產值，或將這些設定放在 Web.Release.config 檔案中，以設定Web.config轉換以在部署期間插入這些設定，它們將會儲存在來源存放庫中。 如果您在生產發行設定檔中輸入資料庫連接字串，密碼會位於 .pubxml 檔案中。 (您可以從原始檔控制中排除 .pubxml 檔案，但您會失去共用所有其他部署設定的優點。)

Azure 可讓您替代Web.config檔案的appSettings和連接字串區段。 以下是 Azure 管理入口網站中網站之 [組 態 ] 索引標籤的相關部分：

入口網站中的 appSettings 和 connectionStrings

當您將專案部署到此網站並執行應用程式時，您儲存在 Azure 中的任何值都會覆寫Web.config檔案中的任何值。

您可以使用管理入口網站或腳本，在 Azure 中設定這些值。 您在[自動化所有專案]章節中看到的環境建立自動化腳本會建立 Azure SQL Database、取得儲存體和SQL Database連接字串，並將這些秘密儲存在網站的設定中。

# Configure app settings for storage account and New Relic
$appSettings = @{ `
    "StorageAccountName" = $storageAccountName; `
    "StorageAccountAccessKey" = $storage.AccessKey; `
    "COR_ENABLE_PROFILING" = "1"; `
    "COR_PROFILER" = "{71DA0A04-7777-4EC6-9643-7D28B46A8A41}"; `
    "COR_PROFILER_PATH" = "C:\Home\site\wwwroot\newrelic\NewRelic.Profiler.dll"; `
    "NEWRELIC_HOME" = "C:\Home\site\wwwroot\newrelic" `
}

# Configure connection strings for appdb and ASP.NET member db
$connectionStrings = ( `
    @{Name = $sqlAppDatabaseName; Type = "SQLAzure"; ConnectionString = $sql.AppDatabase.ConnectionString}, `
    @{Name = "DefaultConnection"; Type = "SQLAzure"; ConnectionString = $sql.MemberDatabase.ConnectionString}
)

請注意，腳本會參數化，讓實際值不會保存到來源存放庫。

當您在開發環境中本機執行時，應用程式會讀取本機Web.config檔案，而您的連接字串會指向 Web 專案App_Data資料夾中的 LocalDB SQL Server 資料庫。 當您在 Azure 中執行應用程式，而應用程式會嘗試從Web.config檔案讀取這些值時，會傳回並使用的值是儲存網站的值，而不是Web.config檔案中實際儲存的值。

在 Visual Studio 和 Azure DevOps 中使用 Git

您可以使用任何原始檔控制環境來實作稍早呈現的 DevOps 分支結構。 針對分散式小組， 分散式版本控制系統 (DVCS) 可能最適合;對於其他小組而言， 集中式系統 可能會更好。

Git 是熱門的分散式版本控制系統。 當您使用 Git 進行原始檔控制時，您具有本機電腦上所有歷程記錄的完整存放庫複本。 許多人偏好這麼做，因為當您未連線到網路時，可以更輕鬆地繼續工作-- 您可以繼續執行認可和回復、建立和切換分支等等。 即使您已連線到網路，在一切都是本機時，建立分支和切換分支會更容易且更快速。 您也可以執行本機認可和復原，而不會影響其他開發人員。 而且您可以在將認可傳送至伺服器之前批次處理認可。

Azure Repos提供Git和Team Foundation 版本控制 ( TFVC;集中式原始檔控制) 。 在這裡開始使用 Azure DevOps。

Visual Studio 2017 包含內建的頂級 Git 支援。 以下是運作方式的快速示範。

在 Visual Studio 中開啟專案後，以滑鼠右鍵按一下Solution Explorer中的方案，然後選擇 [將方案新增至原始檔控制]。

將方案新增至原始檔控制

Visual Studio 詢問您是否要使用 TFVC (集中式版本控制) 或 Git。

選擇原始檔控制

當您選取 [Git] 並按一下 [ 確定] 時，Visual Studio 會在您的方案資料夾中建立新的本機 Git 存放庫。 新的存放庫還沒有任何檔案;您必須執行 Git 認可，將其新增至存放庫。 以滑鼠右鍵按一下Solution Explorer中的方案，然後按一下 [認可]。

Commit

Visual Studio 會自動暫存認可的所有專案檔，並在 [包含的變更] 窗格中的[Team Explorer] 中列出它們。 (如果有些您不想包含在認可中，您可以選取它們、按一下滑鼠右鍵，然後按一下 [ Exclude.)

Team Explorer

輸入認可批註，然後按一下 [ 認可]，Visual Studio 會執行認可並顯示認可識別碼。

Team Explorer 變更

現在，如果您變更一些程式碼，使其與存放庫中的內容不同，您可以輕鬆地檢視差異。 以滑鼠右鍵按一下您已變更的檔案，選取 [ 與未修改的比較]，並取得顯示未認可的變更的比較顯示。

與未修改的比較

顯示變更的差異

您可以輕鬆地查看您所做的變更，並簽入這些變更。

假設您需要建立分支 ， 您也可以在 Visual Studio 中執行此作業。 在 [Team Explorer] 中，按一下 [ 新增分支]。

Team Explorer 新增分支 - 映射 1

輸入分支名稱，按一下 [ 建立分支]，如果您選取 [簽出分支]，Visual Studio 會自動簽出新的分支。

Team Explorer 新增分支 - 映射 2

您現在可以對檔案進行變更，並簽入此分支。 而且，您可以輕鬆地在分支與 Visual Studio 之間切換，將檔案自動同步至您已取出的分支。在此範例中 ，_Layout.cshtml 中的網頁標題已變更為 HotFix1 分支中的 「Hot Fix 1」。

Hotfix1 分支

如果您切換回 main 分支， _Layout.cshtml 檔案的內容會自動還原成 主要 分支中的內容。

main 分支

這是一個簡單的範例，說明如何快速建立分支，並在分支之間來回翻轉。 此功能使用 自動化所有 專案一章中呈現的分支結構和自動化腳本，來啟用高度敏捷的工作流程。 例如，您可以在開發分支中工作、從 主要分支建立熱修正分支、切換至新分支、在該處進行變更並認可變更，然後切換回開發分支，然後繼續您所做的工作。

您在這裡看到的是如何在 Visual Studio 中使用本機 Git 存放庫。 在小組環境中，您通常也會將變更推送至一般存放庫。 Visual Studio 工具也可讓您指向遠端 Git 存放庫。 您可以針對該用途使用 GitHub.com，也可以使用Git 和 Azure Repos與所有其他 Azure DevOps 功能整合，例如工作專案和 Bug 追蹤。

當然，這不是您可以實作敏捷式分支策略的唯一方式。 您可以使用集中式原始檔控制存放庫來啟用相同的敏捷工作流程。

摘要

根據您可以進行變更的速度，以安全且可預測的方式生存，測量原始檔控制系統的成功程度。 如果您發現自己因為必須進行一天或兩天的手動測試而感到擔心，您可能會問自己必須執行程式或測試動作，以便在幾分鐘或最差的情況下進行該變更，而不再超過一小時。 其中一個做法是實作持續整合和持續傳遞，我們將在 下一章中討論。

資源

如需分支策略的詳細資訊，請參閱下列資源：

如需如何處理不應保留在原始檔控制存放庫中之敏感性資訊的詳細資訊，請參閱下列資源：

如需將敏感性資訊保留在原始檔控制之外之其他方法的資訊，請參閱 ASP.NET MVC：將私人設定保留在原始檔控制之外。

上一個下一個