Merge pull request #48784 from lootle1/MR70

AnnaMHuff · web-flow · commit 0716cbddd417 · 2025-01-29T09:53:27.000-07:00
Technical Review 1016251: Implement a code workflow in your build pip…
diff --git a/learn-pr/azure-devops/implement-code-workflow/1-introduction.yml b/learn-pr/azure-devops/implement-code-workflow/1-introduction.yml
@@ -6,7 +6,7 @@ metadata:
   prefetch-feature-rollout: true
   title: Introduction
   description: See what you'll learn and set up your development environment.
-  ms.date: 10/24/2023
+  ms.date: 1/21/2025
   author: juliakm
   ms.author: jukullam
   ms.custom: devdivchpfy22
diff --git a/learn-pr/azure-devops/implement-code-workflow/10-summary.yml b/learn-pr/azure-devops/implement-code-workflow/10-summary.yml
@@ -6,7 +6,7 @@ metadata:
   prefetch-feature-rollout: true
   title: Summary
   description: This unit summarizes what you've learned and provides additional learning resources.
-  ms.date: 10/24/2023
+  ms.date: 1/21/2025
   author: juliakm
   ms.author: jukullam
   ms.custom: devdivchpfy22
diff --git a/learn-pr/azure-devops/implement-code-workflow/2-choose-a-code-flow-strategy.yml b/learn-pr/azure-devops/implement-code-workflow/2-choose-a-code-flow-strategy.yml
@@ -6,7 +6,7 @@ metadata:
   prefetch-feature-rollout: true
   title: Choose a code-flow strategy
   description: Learn the advantages of using a distributed version-control system such as Git.
-  ms.date: 10/24/2023
+  ms.date: 1/21/2025
   author: juliakm
   ms.author: jukullam
   ms.custom: devdivchpfy22
diff --git a/learn-pr/azure-devops/implement-code-workflow/3-set-up-environment.yml b/learn-pr/azure-devops/implement-code-workflow/3-set-up-environment.yml
@@ -6,7 +6,7 @@ metadata:
   prefetch-feature-rollout: true
   title: Exercise - Set up your Azure DevOps environment
   description: Run a template to set up your Azure DevOps environment.
-  ms.date: 10/24/2023
+  ms.date: 1/21/2025
   author: juliakm
   ms.author: jukullam
   ms.custom: devdivchpfy22
diff --git a/learn-pr/azure-devops/implement-code-workflow/4-create-pull-request.yml b/learn-pr/azure-devops/implement-code-workflow/4-create-pull-request.yml
@@ -6,7 +6,7 @@ metadata:
   prefetch-feature-rollout: true
   title: Exercise - Create a pull request
   description: Use a pull request to propose changes you'd like to make to the codebase.
-  ms.date: 10/24/2023
+  ms.date: 1/21/2025
   author: juliakm
   ms.author: jukullam
   ms.custom: devdivchpfy22
diff --git a/learn-pr/azure-devops/implement-code-workflow/5-push-a-change.yml b/learn-pr/azure-devops/implement-code-workflow/5-push-a-change.yml
@@ -6,7 +6,7 @@ metadata:
   prefetch-feature-rollout: true
   title: Exercise - Push a change through the pipeline
   description: Practice the entire process by adding a feature to a branch and then pushing that branch to GitHub.
-  ms.date: 10/24/2023
+  ms.date: 1/21/2025
   author: juliakm
   ms.author: jukullam
   ms.custom: devdivchpfy22
diff --git a/learn-pr/azure-devops/implement-code-workflow/6-add-build-badge.yml b/learn-pr/azure-devops/implement-code-workflow/6-add-build-badge.yml
@@ -6,7 +6,7 @@ metadata:
   prefetch-feature-rollout: true
   title: Exercise - Add a build badge
   description: Add a build badge to the README.md file on GitHub so others can see its status at a glance.
-  ms.date: 10/24/2023
+  ms.date: 1/21/2025
   author: juliakm
   ms.author: jukullam
   ms.custom: devdivchpfy22
diff --git a/learn-pr/azure-devops/implement-code-workflow/7-track-build-history.yml b/learn-pr/azure-devops/implement-code-workflow/7-track-build-history.yml
@@ -6,7 +6,7 @@ metadata:
   prefetch-feature-rollout: true
   title: Exercise - Track your build history
   description: Add a widget to the dashboard to track the history of your builds.
-  ms.date: 10/24/2023
+  ms.date: 1/21/2025
   author: juliakm
   ms.author: jukullam
   ms.custom: devdivchpfy22
diff --git a/learn-pr/azure-devops/implement-code-workflow/8-require-reviewer.yml b/learn-pr/azure-devops/implement-code-workflow/8-require-reviewer.yml
@@ -6,7 +6,7 @@ metadata:
   prefetch-feature-rollout: true
   title: Exercise - Add a rule to require a review
   description: Set up a rule on GitHub that requires a reviewer to approve changes before they can be merged into the main branch.
-  ms.date: 10/24/2023
+  ms.date: 1/21/2025
   author: juliakm
   ms.author: jukullam
   ms.custom: devdivchpfy22
diff --git a/learn-pr/azure-devops/implement-code-workflow/9-clean-up-environment.yml b/learn-pr/azure-devops/implement-code-workflow/9-clean-up-environment.yml
@@ -6,7 +6,7 @@ metadata:
   prefetch-feature-rollout: true
   title: Exercise - Clean up your Azure DevOps environment
   description: Clean up your Azure DevOps environment and disable your build pipeline.
-  ms.date: 10/24/2023
+  ms.date: 1/21/2025
   author: juliakm
   ms.author: jukullam
   ms.custom: devdivchpfy22
diff --git a/learn-pr/azure-devops/implement-code-workflow/includes/2-choose-a-code-flow-strategy.md b/learn-pr/azure-devops/implement-code-workflow/includes/2-choose-a-code-flow-strategy.md
@@ -54,7 +54,7 @@ What's cool about Azure DevOps is that it works well both with centralized versi
 
 ## How do I work with Git?
 
-**Mara:** Like I mentioned before, with distributed systems, developers are free to access any file they need without affecting other developers' work, because they have their own copy of the repository. A _clone_ is your local copy of a repository.
+**Mara:** Like I mentioned before, with distributed systems, developers are free to access any file they need without affecting other developers' work because they have their own copy of the repository. A _clone_ is your local copy of a repository.
 
 When we work on a feature or a bug fix, we usually want to try out different approaches until we find the best solution. However, trying out code on your copy of the main code base isn't a good idea, because you might not want to keep the first few tries.
 
@@ -94,7 +94,7 @@ Before you make changes to a file, you check out a new branch so that you know y
  :::row:::
     :::column span="8":::
 **Step 3**:
-You're now safe to make whatever changes you want, because these changes are only in your branch. As you work, you can _commit_ your changes to your branch to ensure that you don't lose any work, and to provide a way to roll back any changes you've made to earlier versions. Before you can commit changes, you need to stage your files so that Git knows which ones you're ready to commit.
+You're now safe to make whatever changes you want because these changes are only in your branch. As you work, you can _commit_ your changes to your branch to ensure that you don't lose any work. This also provides a way to roll back any changes you've made to earlier versions. Before you can commit changes, you need to stage your files so that Git knows which ones you're ready to commit.
     :::column-end:::
     :::column:::
         :::image type="content" source="../media/2-github-paths-3.png" border="false" alt-text="Diagram of the commits being made to the local branch.":::
@@ -112,7 +112,7 @@ The next step is to _push_, or upload, your local branch up to the remote reposi
 :::row:::
     :::column span="8":::
 **Step 5**:
-This step is a common one, but not required. When you're satisfied that your code is working as you want it to, you can _pull_, or merge, the remote `main` branch back into your local `main` branch. Changes have been taking place there that your local `main` branch doesn't have yet. After you've synchronized the remote `main` branch with yours, merge your local `main` branch into your working branch and test your build again.
+This step is a common one but not required. When you're satisfied that your code is working as you want it to, you can _pull_, or merge, the remote `main` branch back into your local `main` branch. Changes have been taking place there that your local `main` branch doesn't have yet. After you've synchronized the remote `main` branch with yours, merge your local `main` branch into your working branch and test your build again.
 
 This process helps ensure that your feature works with the latest code. It also helps ensure that your work will integrate smoothly when you submit your pull request.
     :::column-end:::
diff --git a/learn-pr/azure-devops/implement-code-workflow/includes/3-set-up-environment.md b/learn-pr/azure-devops/implement-code-workflow/includes/3-set-up-environment.md
@@ -27,7 +27,7 @@ To run the template, on the Azure DevOps Demo Generator site, do the following:
 1. Select **Yes, I want to fork this repository**, then select **Authorize**. If a window appears, authorize access to your GitHub account.
 
     > [!IMPORTANT]
-    > You need to select this option for the template to connect to your GitHub repository. Select it even if you've already forked the _Space Game_ website project. The template uses your existing fork.
+    > You need to select this option for the template to connect to your GitHub repository. Select it even if you've already forked the *Space Game* website project. The template uses your existing fork.
 
 1. Select **Create Project**.
 
@@ -43,7 +43,7 @@ To run the template, on the Azure DevOps Demo Generator site, do the following:
 
 ## Move the work item to Doing
 
-In this section, you'll assign yourself a work item that relates to this module on Azure Boards. You'll also move the work item to the **Doing** state. In practice, you and your team would create work items at the start of each sprint, or work iteration.
+In this section, you'll assign yourself a work item that relates to this module on Azure Boards. You'll also move the work item to the **Doing** state. In practice, you and your team would create work items at the start of each sprint or work iteration.
 
 Assigning work in this way gives you a checklist from which to work. It gives others on your team visibility into what you're working on and how much work is left. It also helps the team enforce work in process (WIP) limits so that the team doesn't take on too much work at one time.
 
diff --git a/learn-pr/azure-devops/implement-code-workflow/includes/4-create-pull-request.md b/learn-pr/azure-devops/implement-code-workflow/includes/4-create-pull-request.md
@@ -8,7 +8,7 @@ Recall that a *pull request* tells the other developers that you have code ready
 
 Before we start, let's check in with Mara and Andy.
 
-**Andy:** Hi, Mara. I know you've got a build pipeline running on Azure. I'm adding a feature to the website and I want to see the build process for myself. Are we ready to do that?
+**Andy:** Hi, Mara. I know you've got a build pipeline running on Azure. I'm adding a feature to the website, and I want to see the build process for myself. Are we ready to do that?
 
 **Mara:** Absolutely. I created the pipeline on a branch. Why don't we create a pull request and get it merged into `main` so you can use the pipeline, too?
 
@@ -124,7 +124,7 @@ Here, you'll create a pull request for your branch:
     > [!IMPORTANT]
     > This step is important because you can't merge your changes into the Microsoft repository. Ensure that the base repository points to your GitHub account and not MicrosoftDocs.
     >
-    > If you end up with a pull request against MicrosoftDocs, simply close the pull request and repeat these steps.
+    > If you end up with a pull request against MicrosoftDocs, close the pull request and repeat these steps.
 
     This process involves an extra step because you're working from a forked repository. When you work directly with your own repository, and not a fork, your `main` branch is selected by default.
 
@@ -139,7 +139,7 @@ Here, you'll create a pull request for your branch:
 
 1. To complete your pull request, select **Create pull request**.
 
-    This step does not merge any code. It tells others that you have proposed changes to be merged into the `main` branch.
+    This step doesn't merge any code. It tells others that you have proposed changes to be merged into the `main` branch.
 
     :::image type="content" source="../media/4-github-pr-details.png" alt-text="Screenshot of GitHub showing the pull request description and the location of the Create pull request button.":::
 
@@ -167,7 +167,7 @@ Here, you'll create a pull request for your branch:
 
     :::image type="content" source="../media/4-github-delete-branch.png" alt-text="Screenshot of GitHub showing the location of the Delete branch button.":::
 
-    It's completely safe to delete a branch from GitHub after you've merged your pull request. In fact, it's a common practice, because the branch is no longer needed. The changes are merged and you can still find the details about the changes on GitHub or from the command line. Deleting a merged branch also helps others see only the work that's currently active.
+    It's completely safe to delete a branch from GitHub after you've merged your pull request. In fact, it's a common practice, because the branch is no longer needed. The changes are merged, and you can still find the details about the changes on GitHub or from the command line. Deleting a merged branch also helps others see only the work that's currently active.
 
     Git branches are meant to be short-lived. After you merge a branch, you don't push additional commits onto it or merge it a second time. In most cases, every time you start on a new feature or bug fix, you start with a clean branch that's based on the `main` branch.
 
diff --git a/learn-pr/azure-devops/implement-code-workflow/includes/5-push-a-change.md b/learn-pr/azure-devops/implement-code-workflow/includes/5-push-a-change.md
@@ -5,12 +5,12 @@ Mara has been given the task of changing some text on the home page of the websi
 Let's briefly review the steps to follow to complete the task:
 
 > [!div class="checklist"]
-> * Synchronize your local repository with the latest `main` branch on GitHub
-> * Create a branch to hold your changes
-> * Make the code changes you need, and verify them locally
-> * Push your branch to GitHub
-> * Merge any recent changes from the `main` branch on GitHub into your local working branch, and verify that your changes still work
-> * Push up any remaining changes, watch Azure Pipelines build the application, and submit your pull request
+> * Synchronize your local repository with the latest `main` branch on GitHub.
+> * Create a branch to hold your changes.
+> * Make the code changes you need, and verify them locally.
+> * Push your branch to GitHub.
+> * Merge any recent changes from the `main` branch on GitHub into your local working branch, and verify that your changes still work.
+> * Push up any remaining changes, watch Azure Pipelines build the application, and submit your pull request.
 
 ## Fetch the latest main branch
 
@@ -71,7 +71,7 @@ You should see this:
 
 You can interact with the page, including the leaderboard. When you select a player's name, you see details about that player.
 
-When you're finished, return to the terminal window and select <kbd>Ctrl+C</kbd> to stop the running application.
+When you're finished, return to the terminal window, and select <kbd>Ctrl+C</kbd> to stop the running application.
 
 ## Create a feature branch
 
@@ -173,9 +173,9 @@ As an optional step, trace the build as it moves through the pipeline, and verif
 
 While you were busy working on your feature, changes might have been made to the remote `main` branch. Before you create a pull request, it's common practice to get the latest from the remote `main` branch.
 
-To do this, first check out, or switch to, the `main` branch, then merge the remote `main` branch with your local `main` branch.
+To do this, first check out, or switch to, the `main` branch. Then, merge the remote `main` branch with your local `main` branch.
 
-Next, check out your feature branch, then merge your feature branch with the `main` branch.
+Next, check out your feature branch, and then merge your feature branch with the `main` branch.
 
 Let's try the process now.
 
diff --git a/learn-pr/azure-devops/implement-code-workflow/includes/8-require-reviewer.md b/learn-pr/azure-devops/implement-code-workflow/includes/8-require-reviewer.md
@@ -1,6 +1,6 @@
 In this unit, you'll set up a rule on GitHub that requires a reviewer to approve changes before they can be merged into the `main` branch. As a bonus, you'll also fix the typing error on the *Space Game* website's home page.
 
-Currently, the team allows anyone who makes a pull request to merge the code into the `main` branch. Because no review is required, it's possible for incorrect or unstable code to creep in.
+Currently, the team allows anyone who makes a pull request to merge the code into the `main` branch. Because no review is required, it's possible for incorrect or unstable code to find its way in.
 
 Andy decides that he wants to add a check to the pull request in the form of another pair of eyes. He wants to set up GitHub to require someone other than the pull request author to review the code before it's merged. Let's see how to do this.
 
@@ -26,7 +26,7 @@ In this section, you'll set up a rule on GitHub that requires at least one revie
 1. Select the **Settings** tab near the top of the page.
 1. On the left menu, select **Branches**.
 1. Make sure that **main** is selected as your default branch.
-1. Select **Add branch protection rule**.
+1. Select **Add classic branch protection rule**.
 1. Under **Branch name pattern**, enter **main**.
 1. Select the **Require a pull request before merging** check box.
 1. Select the **Require approvals** check box.
@@ -39,7 +39,7 @@ In this section, you'll set up a rule on GitHub that requires at least one revie
 
 ### Submit the fix
 
-In this section, you submit a fix to the typing error on the home page. Remember that the word "official" is mistyped as "oficial".
+In this section, you submit a fix to the typing error on the home page. Remember that the word "official" is mistyped as "oficial."
 
  :::image type="content" source="../media/5-web-site-revised-text.png" alt-text="Screenshot of the Space Game website showing a typing error.":::
 
diff --git a/learn-pr/azure-devops/implement-code-workflow/includes/9-clean-up-environment.md b/learn-pr/azure-devops/implement-code-workflow/includes/9-clean-up-environment.md
@@ -36,7 +36,7 @@ To disable the pipeline:
 1. Select the ellipsis (**...**), then select **Settings**:
 
     :::image type="content" source="../../shared/media/azure-pipelines-settings-button.png" alt-text="Screenshot of Azure Pipelines showing the location of the Settings menu.":::
-1. Under **Processing of new run requests**, select **Disabled**, then select **Save**.
+1. Under **Processing of new run requests**, select **Disabled**, and then select **Save**.
 
     Your pipeline will no longer process build requests.
 
diff --git a/learn-pr/azure-devops/implement-code-workflow/index.yml b/learn-pr/azure-devops/implement-code-workflow/index.yml
@@ -5,7 +5,7 @@ metadata:
   prefetch-feature-rollout: true
   title: Implement a code workflow in your build pipeline by using Git and GitHub
   description: Learn along with the Space Game web team the benefits of collaboration through Visual Studio Code and GitHub.
-  ms.date: 10/24/2023
+  ms.date: 1/21/2025
   author: juliakm
   ms.author: jukullam
   ms.custom: devdivchpfy22
