Further edits

Author: gitName

learn-pr/azure-devops/create-multi-stage-pipeline/includes/3-set-up-environment.md

@@ -37,8 +37,8 @@ Run a template that sets up your Azure DevOps organization.
 
 1. Choose your authentication method. You can [set up and use a Personal Access Token (PAT)](/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate#create-a-pat) or use device login.
 
-	> [!NOTE]
-	> If you set up a PAT, make sure to authorize the necessary [scopes](/azure/devops/integrate/get-started/authentication/oauth#scopes). For this module, you can use **Full access**, but in a real-world situation, you should ensure you grant only the necessary scopes.
+    > [!NOTE]
+    > If you set up a PAT, make sure to authorize the necessary [scopes](/azure/devops/integrate/get-started/authentication/oauth#scopes). For this module, you can use **Full access**, but in a real-world situation, you should ensure you grant only the necessary scopes.
 
 1. Enter your Azure DevOps organization name, then press **Enter**.
 
@@ -67,7 +67,7 @@ If you haven't already, create a fork of the **mslearn-tailspin-spacegame-web-de
 
 Here, you assign a work item to yourself on Azure Boards. You 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.
 
-This work assignment gives you a checklist to work from. It gives other team members visibility into what you're working on and how much work is left. The work item also helps enforce work-in-progress (WIP) limits so that the team doesn't take on too much work at one time.
+This work assignment gives you a checklist from which to work. It gives other team members visibility into what you're working on and how much work is left. The work item also helps enforce work-in-progress (WIP) limits so that the team doesn't take on too much work at one time.
 
 Recall that the team settled on the following top issues for the current sprint.
 
@@ -82,15 +82,15 @@ To set up the work item:
 
 1. From Azure DevOps, go to **Boards**. Then, from the menu, select **Boards**.
 
-    :::image type="content" source="../../shared/media/azure-devops-boards-menu.png" alt-text="A screenshot of Azure DevOps showing the location of the Boards menu.":::
+    :::image type="content" source="../../shared/media/azure-devops-boards-menu.png" alt-text="Screenshot of Azure DevOps showing the location of the Boards menu.":::
 
 1. In the **Create a multistage pipeline** card, select the down arrow. Then, assign the work item to yourself.
 
     :::image type="content" source="../../shared/media/azure-boards-down-chevron.png" alt-text="Screenshot of Azure Boards showing the location of the down arrow.":::
 
 1. Move the work item from the **To Do** column to the **Doing** column.
 
-    :::image type="content" source="../media/3-azure-boards-wi1-doing.png" alt-text="A screenshot of Azure Boards showing the card in the Doing column.":::
+    :::image type="content" source="../media/3-azure-boards-wi1-doing.png" alt-text="Screenshot of Azure Boards showing the card in the Doing column.":::
 
 At the end of this module, you'll move the card to the **Done** column, after you complete the task.
 
@@ -109,7 +109,7 @@ In this module, you use the Azure CLI to bring up three App Service instances. Y
 
 ### Bring up Cloud Shell through the Azure portal
 
-1. Go to the [Azure portal](https://portal.azure.com?azure-portal=true), and sign in.
+1. Go to the [Azure portal](https://portal.azure.com?azure-portal=true) and sign in.
 1. From the menu, select **Cloud Shell**. When prompted, select the **Bash** experience.
 
     :::image type="content" source="../../shared/media/azure-portal-menu-cloud-shell.png" alt-text="A screenshot of the Azure portal showing the location of the Cloud Shell menu item.":::
@@ -165,7 +165,7 @@ Here, you create the App Service instances for the three stages you deploy to: *
 1. Verify that each environment is running, and that the home page is accessible.
 
    > [!NOTE]
-   > For learning purposes, here, you use the default network settings. These settings make your site accessible from the internet. In practice, you could configure an Azure virtual network that places your website in a network that's not internet routable, and that only you and your team can access. Later, you could reconfigure your network to make the website available to your users.
+   > For learning purposes, you use the default network settings here. These settings make your site accessible from the internet. In practice, you could configure an Azure virtual network that places your website in a network that's not internet routable, and that only you and your team can access. Later, you could reconfigure your network to make the website available to your users.
 
 To create your App Service instances, follow these steps:
 
@@ -203,28 +203,28 @@ To create your App Service instances, follow these steps:
       --name tailspin-space-game-web-dev-$webappsuffix \
       --resource-group tailspin-space-game-rg \
       --plan tailspin-space-game-asp \
-      --runtime "DOTNET|6.0"
+      --runtime "DOTNETCORE|8.0"
 
     az webapp create \
       --name tailspin-space-game-web-test-$webappsuffix \
       --resource-group tailspin-space-game-rg \
       --plan tailspin-space-game-asp \
-      --runtime "DOTNET|6.0"
+      --runtime "DOTNETCORE|8.0"
 
     az webapp create \
       --name tailspin-space-game-web-staging-$webappsuffix \
       --resource-group tailspin-space-game-rg \
       --plan tailspin-space-game-asp \
-      --runtime "DOTNET|6.0"
+      --runtime "DOTNETCORE|8.0"
     ```
 
-    For learning purposes, here, you apply the same App Service plan, B1 Basic, to each App Service instance. In practice, you would assign a plan that matches your expected workload.
+    For learning purposes, you apply the same App Service plan, B1 Basic, to each App Service instance here. In practice, you'd assign a plan that matches your expected workload.
 
     For example, for the environments that map to the *Dev* and *Test* stages, B1 Basic might be appropriate because you want only your team to access the environments.
 
-    For the *Staging* environment, you would select a plan that matches your production environment. That plan would likely provide greater CPU, memory, and storage resources. Under the plan, you can run performance tests, like load tests, in an environment that resembles your production environment. You can run the tests without affecting live traffic to your site.
+    For the *Staging* environment, you'd select a plan that matches your production environment. That plan would likely provide greater CPU, memory, and storage resources. Under the plan, you can run performance tests, like load tests, in an environment that resembles your production environment. You can run the tests without affecting live traffic to your site.
 
-1. To list the host name and state of each App Service instance, run the following `az webapp list` command.
+1. To list each App Service instance's host name and state, run the following `az webapp list` command.
 
     ```azurecli
     az webapp list \
@@ -280,7 +280,7 @@ To add the variables:
     > [!IMPORTANT]
     > Set the name of the App Service instance, not its host name. In this example, you would enter *tailspin-space-game-web-dev-1234* and not *tailspin-space-game-web-dev-1234.azurewebsites.net*.
 
-1. Near the beginning of the page, select **Save** to save your variable in the pipeline.
+1. Near the top of the page, select **Save** to save your variable in the pipeline.
 
     Your variable group resembles this one:
 
@@ -317,8 +317,8 @@ Here, you create a service connection that enables Azure Pipelines to access you
 1. In Azure DevOps, go to your **Space Game - web - Multistage** project.
 1. From the lower-left corner of the page, select **Project settings**.
 1. Under **Pipelines**, select **Service connections**.
-1. Select **New service connection**, then select **Azure Resource Manager**, and then select **Next**.
-1. At the beginning of the page, select **Service principal (automatic)**. Then, select **Next**.
+1. Select **Create service connection**, then select **Azure Resource Manager**, and then select **Next**.
+1. At the beginning of the page, select **App registration (automatic)**. Then, select **Next**.
 1. Fill in these fields:
 
     | Field                   | Value                                      |

learn-pr/azure-devops/create-multi-stage-pipeline/includes/6-promote-staging.md

@@ -26,10 +26,7 @@ To create the **staging** environment:
 1. Under **Name**, enter *staging*.
 1. Leave the remaining fields at their default values.
 1. Select **Create**.
-1. On the **staging** environment page, open the dropdown, and then select **Approvals and checks**.
-
-    :::image type="content" source="../../shared/media/pipeline-add-check-to-environment.png" alt-text="A screenshot of Azure Pipelines, showing the location of the approvals and checks menu item.":::
-
+1. On the **staging** environment page, select the **Approvals and checks** tab.
 1. Select **Approvals**.
 1. Under **Approvers**, select **Add users and groups**, and then select your account.
 1. Under **Instructions to approvers**, enter *Approve this change when it's ready for staging*.
@@ -91,6 +88,6 @@ The Tailspin team gathers to discuss their progress. Amita approves changes in t
 
 **Tim:** To tell you the truth, at first I was a little nervous about automated release pipelines. But I really like this now that I see it working. Each stage can have its own environment, associated tests, and approvers. The pipeline automates many things that we had to do manually. But we still have control where we need it.
 
-**Amita:** I could imagine us doing something similar to promote changes from *Staging* to *Production*. Speaking of...when do we add a **production** environment?
+**Amita:** I could imagine us doing something similar to promote changes from *Staging* to *Production*. Speaking of, when do we add a **production** environment?
 
 **Andy:** Shortly. I think we still need to fill in a few pieces here first before we add that.

learn-pr/azure-devops/create-multi-stage-pipeline/includes/7-clean-up-environment.md

@@ -7,7 +7,7 @@ You're finished with the tasks for this module. In this unit, you clean up your
 
 Here, you delete your Azure App Service instances. The easiest way to delete the instances is to delete their parent resource group. When you delete a resource group, you delete all resources in that group.
 
-In the [Create a release pipeline with Azure Pipelines](/training/modules/create-release-pipeline?azure-portal=true) module, you managed Azure resources through the Azure portal. Here you tear down your deployment by using the Azure CLI through Azure Cloud Shell. The steps are similar to the steps that you used when you created the resources.
+In the [Create a release pipeline with Azure Pipelines](/training/modules/create-release-pipeline?azure-portal=true) module, you managed Azure resources through the Azure portal. Here, you can tear down your deployment by using the Azure CLI through Azure Cloud Shell. The steps are similar to the steps that you used when you created the resources.
 
 To clean up your resource group:
 
@@ -77,7 +77,7 @@ To delete the project:
 
 1. In Azure DevOps, go to your project. Earlier, we recommended that you name this project **Space Game - web - Multistage**.
 1. Select **Project settings** in the lower-left corner of your Azure DevOps page.
-1. In the **Project details** area, scroll down, and select **Delete**.
+1. In the **Project details** area, scroll down and select **Delete**.
 
     :::image type="content" source="../../shared/media/azure-devops-delete-project.png" alt-text="A screenshot of Azure Pipelines showing the location of the Delete button.":::
 1. In the window that appears, enter the project name. Select **Delete** again.

learn-pr/azure-devops/create-multi-stage-pipeline/includes/8-summary.md

@@ -8,7 +8,7 @@ The *Dev*, *Test*, and *Staging* stages each deploy the build artifact to their
 
 - When a change is pushed to GitHub, a *trigger* causes the *Build* stage to run. The *Build* stage produces a build artifact as its output.
 - The *Dev* stage runs only when the change happens in the *release* branch. You use a *condition* to specify this requirement.
-- The *Test* stage runs at 3 A.M. each morning. This stage runs only when the *release* branch contains changes since the last run. You use a *scheduled trigger* to specify when the *Test* stage runs.
+- The *Test* stage runs at 3 A.M. each day. This stage runs only when the *release* branch contains changes since the last run. You use a *scheduled trigger* to specify when the *Test* stage runs.
 - The *Staging* stage runs only after you approve the changes in the *Test* stage. You add a *release approval* to the **staging** environment to pause the pipeline until you approve or reject the change.
 
 This pipeline satisfies the requirements of the Tailspin team. Your pipeline's shape and how changes flow through it depend on the needs of your team, and of the apps and services that you build.
@@ -19,6 +19,6 @@ Although the team is improving their release cadence, there's room for more impr
 
 In this module, you worked with conditions, triggers, and approvals. To learn more, explore these resources.
 
-* [Conditions](/azure/devops/pipelines/process/conditions?azure-portal=true&tabs=yaml)
-* [Build pipeline triggers](/azure/devops/pipelines/build/triggers?azure-portal=true&tabs=yaml)
-* [Approvals and other checks](/azure/devops/pipelines/process/approvals?azure-portal=true)
+- [Conditions](/azure/devops/pipelines/process/conditions?azure-portal=true&tabs=yaml)
+- [Build pipeline triggers](/azure/devops/pipelines/build/triggers?azure-portal=true&tabs=yaml)
+- [Approvals and other checks](/azure/devops/pipelines/process/approvals?azure-portal=true)