練習 - 建立提取要求

12 分鐘

您會在此單元中練習提交提取要求的流程，並將變更合併至 main 分支，以便讓所有人受益於您的工作。

在使用 Azure Pipelines 建立組建管線中，您已建立名為 build-pipeline 的 Git 分支，並於其中定義 Space Game 網站的基本組建管線。請記得，組建定義位於名稱為 azure-pipelines.yml 的檔案。

雖然您的分支會產生組建成品，但該工作只存在於 build-pipeline 分支。您必須將分支合併至 main 分支。

請記得，提取要求告知其他開發人員您已有可供檢閱的程式碼 (如有必要)，且您要將變更合併至另一個分支，例如 main 分支。

開始前，讓我們先看看 Mara 和 Andy 怎麼說。

Andy：嗨，Mara。我知道你已經有在 Azure 上執行的組建管線。我要將某個功能新增至網站，所以想要看看自己的組建程序。我們已經可以這麼做了嗎？

Mara：當然可以。我已在分支上建立管線。我們何不建立提取要求並合併至 main，如此您也可使用管線？

Andy：聽起來很棒。讓我看看。

建立分支並新增起始程式碼

讓我們建立名稱為 code-workflow 的新分支 (但您可使用上一個課程模組所建置的組建管線)。此分支以 main 為基礎，因此您可從頭開始練習此流程。

在 Visual Studio Code 中，開啟整合式終端。
切換至 main 分支：
```
git checkout main
```
確定您擁有 GitHub 中的最新版程式碼：
```
git pull origin main
```
建立名為 code-workflow 的分支：
```
git checkout -B code-workflow
```
-b 引數會指定建立新分支 (若仍沒有)。若要切換至現有分支，則可省略 -b 引數。

依預設，新分支會在已執行 git checkout 命令的先前分支上建置。此處的父分支為 main，但父分支也可以是另一個分支，例如某功能分支由他人啟動，而您想要將其作為建置基礎，或據以進行實驗。

由於您是在自己的本機分支上，因此現在可安全進行任何所需變更。若要查看目前的分支，請執行 git branch -v。

從檔案總管開啟 azure-pipelines.yml，並取代為下列內容：

trigger:
- '*'

pool:
  vmImage: 'ubuntu-20.04'
  demands:
  - npm

variables:
  buildConfiguration: 'Release'
  wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
  dotnetSdkVersion: '6.x'

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK $(dotnetSdkVersion)'
  inputs:
    version: '$(dotnetSdkVersion)'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: $(wwwrootDir)

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Build the project - $(buildConfiguration)'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration $(buildConfiguration)'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - $(buildConfiguration)'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
    zipAfterPublish: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

這項設定與您在先前課程模組中建立的基本設定類似。為了簡潔起見，其只會建置您專案的發行設定。

將您的分支推送至 GitHub

在此，您會將 code-workflow 分支推送至 GitHub，並觀察 Azure Pipelines 建置應用程式。

在終端中，執行 git status 以查看分支上有哪些未認可的工作：
```
git status
```
您可看到 azure-pipelines.yml 已修改。稍後您會將該檔案認可至您的分支，但須先確定 Git 正在追蹤此檔案 (稱為暫存檔案)。

當您執行 git commit 時，只有暫存的變更會進行認可。接下來，請執行 git add 命令，將 azure-pipelines.yml 新增至暫存區域 (或索引)。
執行下列 git add 命令，將 azure-pipelines.yml 新增至暫存區域：
```
git add azure-pipelines.yml
```
執行下列 git commit 命令，將您暫存的檔案認可至 code-workflow 分支：
```
git commit -m "Add the build configuration"
```
-m 引數會指定認可訊息。認可訊息會成為已變更檔案歷程記錄的一部分。該訊息可協助檢閱者了解變更，並協助未來的維護者了解檔案在這段時間內的變更。

提示

最佳認可訊息會完成這樣的句子「若您套用此認可，您將會...」

若您省略 -m 引數，Git 會開啟文字編輯器，以供您詳述變更。當您要指定跨越多行的認可訊息時，則適用此選項。到第一個空白行為止的文字會指定認可標題。
執行此 git push 命令，將 code-workflow 分支推送或上傳至 GitHub 上的存放庫：
```
git push origin code-workflow
```
(選擇性步驟) 移至您在 Azure Pipelines 中的專案，並在組建執行時加以追蹤。

此組建稱為 CI 組建。您的管線設定會使用所謂的觸發程序，以控制參與組建流程的分支。此處的「*」會指定所有分支。
```
trigger:
- '*'
```
稍後，您將了解如何控制管線設定，以便只從您需要的分支進行建置。

您會看到組建順利完成並產生成品，其中包含已建置的 Web 應用程式。

建立提取要求

在這裡，您會建立分支的提取要求：

在瀏覽器中，登入 GitHub。
移至您的 mslearn-tailspin-spacegame-web 存放庫。
在 [分支] 下拉式清單中，選取您的 code-workflow 分支。
若要啟動您的提取要求，請選取 [參與]，並選取 [開啟提取要求]。
確認 [基底] 指定了您派生的存放庫，而非 Microsoft 的存放庫。

您所進行的選取如下所示：

重要

此步驟很重要，因為您無法將變更合併到 Microsoft 存放庫。請確定基底存放庫指向您的 GitHub 帳戶，而不是 MicrosoftDocs。

如果您最終提出的是針對 MicrosoftDocs 的提取要求，只要關閉該提取要求並重複上述步驟即可。

此流程包含額外的步驟，因為您是從派生的存放庫中進行工作。若您直接使用自己的存放庫，而非分支存放庫，則依預設會選取您的 main 分支。
輸入提取要求的標題和描述。
- 標題:
  
  設定 Azure Pipelines
- 描述：
  
  此管線設定會建置應用程式，並產生發行設定的組建。
若要完成您的提取要求，請選取 [建立提取要求]。

此步驟不會合併任何程式碼。此步驟會通知其他人您提議將變更合併至 main 分支。

[提取要求] 視窗隨即顯示。您會看到已將 Azure Pipelines 中的組建狀態已設定顯示為提取要求的一部分。如此當組建執行時，您與其他人便可檢視組建的狀態。

和您將分支推送至 GitHub 時相仿，提取要求依預設會觸發 Microsoft Azure Pipelines 來建置您的應用程式。

提示

如果您沒有立即看到組建狀態出現，請稍候片刻或重新整理頁面。
(選擇性) 選取 [詳細資料] 連結，並在組建通過管線時進行追蹤。

您可以將組建交付給此流程的下一個步驟，例如 QA。稍後您可設定管線，將變更完全推送至 QA 實驗室或實際執行環境。
返回您在 GitHub 上的提取要求。

等待建置完成。您現已準備好合併提取要求。
選取 [合併提取要求]，接著選取 [確認合併]。
若要從 GitHub 刪除 code-workflow 分支，請選取 [刪除分支]。

在合併提取要求後，即可安全無虞地從 GitHub 中刪除分支。事實上，這是常見的做法，因為不再需要分支。變更會合併，而您仍然可在 GitHub 上或從命令列中找到有關變更的詳細資料。刪除合併的分支，也可協助其他人僅查看目前作用中的工作。

Git 分支應是短期存在的。當您合併分支後，您不會將其他認可推送至其本身或第二次合併它。大多數情況下，每當您開始處理新功能或錯誤修正時，都會從以 main 分支為基礎的全新分支開始。

在 GitHub 上刪除分支，不會從您的本機系統中刪除該分支。若要進行，您要將 -d 參數傳遞至 git branch 命令。

變更建置了多少次？

答案取決於您定義組建組態的方式。 Azure Pipelines 可讓您定義觸發程序，以指定哪些事件會導致組建發生。您可控制要建置哪些分支，或甚至哪些檔案會觸發組建。

例如，假設您要在任何 Git 分支上將變更推送至 GitHub 時進行組建。但當只有專案 docs 資料夾中的檔案變更時，則不要進行組建。您可能要在組建組態中包含此 trigger 區段：

trigger:
  branches:
    include:
    - '*'     # build all branches
  paths:
    exclude:
    - docs/*  # exclude the docs folder

根據預設，組建會在將變更推送至任何分支上的任何檔案時觸發。

持續整合 (CI) 組建是將變更推送至分支時所執行的組建。

提取要求 (PR) 組建是開啟提取要求、或將額外變更推送至現有的提取要求時所執行的組建。

透過 code-workflow 分支所做的變更會在三種情況下進行建置：

當您將變更推送至 code-workflow 分支時，即會發生 CI 組建。
當您根據 main 分支在 code-workflow 分支上開啟提取要求時，即會發生 PR 組建。
將提取要求合併至 main 分支後，就會發生最終的 CI 組建。

PR 組建可協助確認您建議的變更會在合併至 main 或另一個目標分支後正常運作。

最終的 CI 組建會驗證變更在合併 PR 後仍為良好狀態。

選擇性移至 Azure Pipelines，並監看最終的 CI 組建會在 main 分支上發生。

練習 - 建立提取要求

建立分支並新增起始程式碼

將您的分支推送至 GitHub

建立提取要求

變更建置了多少次？

意見反應