Updated YAML lab to cover a full CI/CD pipeline.

nikonorov-d · May 6, 2019 · fbaaed9 · fbaaed9
1 parent 5e09d4e
commit fbaaed9
Show file tree

Hide file tree

Showing 43 changed files with 102 additions and 53 deletions.
diff --git a/labs/azuredevops/yaml/images/000.png b/labs/azuredevops/yaml/images/000.png
diff --git a/labs/azuredevops/yaml/images/001.png b/labs/azuredevops/yaml/images/001.png
diff --git a/labs/azuredevops/yaml/images/002.png b/labs/azuredevops/yaml/images/002.png
diff --git a/labs/azuredevops/yaml/images/003.png b/labs/azuredevops/yaml/images/003.png
diff --git a/labs/azuredevops/yaml/images/004.png b/labs/azuredevops/yaml/images/004.png
diff --git a/labs/azuredevops/yaml/images/005.png b/labs/azuredevops/yaml/images/005.png
diff --git a/labs/azuredevops/yaml/images/006.png b/labs/azuredevops/yaml/images/006.png
diff --git a/labs/azuredevops/yaml/images/007.png b/labs/azuredevops/yaml/images/007.png
diff --git a/labs/azuredevops/yaml/images/008.png b/labs/azuredevops/yaml/images/008.png
diff --git a/labs/azuredevops/yaml/images/009.png b/labs/azuredevops/yaml/images/009.png
diff --git a/labs/azuredevops/yaml/images/010.png b/labs/azuredevops/yaml/images/010.png
diff --git a/labs/azuredevops/yaml/images/011.png b/labs/azuredevops/yaml/images/011.png
diff --git a/labs/azuredevops/yaml/images/012.png b/labs/azuredevops/yaml/images/012.png
diff --git a/labs/azuredevops/yaml/images/013.png b/labs/azuredevops/yaml/images/013.png
diff --git a/labs/azuredevops/yaml/images/014.png b/labs/azuredevops/yaml/images/014.png
diff --git a/labs/azuredevops/yaml/images/015.png b/labs/azuredevops/yaml/images/015.png
diff --git a/labs/azuredevops/yaml/images/016.png b/labs/azuredevops/yaml/images/016.png
diff --git a/labs/azuredevops/yaml/images/017.png b/labs/azuredevops/yaml/images/017.png
diff --git a/labs/azuredevops/yaml/images/018.png b/labs/azuredevops/yaml/images/018.png
diff --git a/labs/azuredevops/yaml/images/019.png b/labs/azuredevops/yaml/images/019.png
diff --git a/labs/azuredevops/yaml/images/020.png b/labs/azuredevops/yaml/images/020.png
diff --git a/labs/azuredevops/yaml/images/021.png b/labs/azuredevops/yaml/images/021.png
diff --git a/labs/azuredevops/yaml/images/022.png b/labs/azuredevops/yaml/images/022.png
diff --git a/labs/azuredevops/yaml/images/023.png b/labs/azuredevops/yaml/images/023.png
diff --git a/labs/azuredevops/yaml/images/024.png b/labs/azuredevops/yaml/images/024.png
diff --git a/labs/azuredevops/yaml/images/025.png b/labs/azuredevops/yaml/images/025.png
diff --git a/labs/azuredevops/yaml/images/026.png b/labs/azuredevops/yaml/images/026.png
diff --git a/labs/azuredevops/yaml/images/027.png b/labs/azuredevops/yaml/images/027.png
diff --git a/labs/azuredevops/yaml/images/028.png b/labs/azuredevops/yaml/images/028.png
diff --git a/labs/azuredevops/yaml/images/029.png b/labs/azuredevops/yaml/images/029.png
diff --git a/labs/azuredevops/yaml/images/030.png b/labs/azuredevops/yaml/images/030.png
diff --git a/labs/azuredevops/yaml/images/031.png b/labs/azuredevops/yaml/images/031.png
diff --git a/labs/azuredevops/yaml/images/032.png b/labs/azuredevops/yaml/images/032.png
diff --git a/labs/azuredevops/yaml/images/033.png b/labs/azuredevops/yaml/images/033.png
diff --git a/labs/azuredevops/yaml/images/034.png b/labs/azuredevops/yaml/images/034.png
diff --git a/labs/azuredevops/yaml/images/035.png b/labs/azuredevops/yaml/images/035.png
diff --git a/labs/azuredevops/yaml/images/036.png b/labs/azuredevops/yaml/images/036.png
diff --git a/labs/azuredevops/yaml/images/037.png b/labs/azuredevops/yaml/images/037.png
diff --git a/labs/azuredevops/yaml/images/038.png b/labs/azuredevops/yaml/images/038.png
diff --git a/labs/azuredevops/yaml/images/039.png b/labs/azuredevops/yaml/images/039.png
diff --git a/labs/azuredevops/yaml/images/040.png b/labs/azuredevops/yaml/images/040.png
diff --git a/labs/azuredevops/yaml/images/041.png b/labs/azuredevops/yaml/images/041.png
diff --git a/labs/azuredevops/yaml/readme.md b/labs/azuredevops/yaml/readme.md
@@ -1,168 +1,217 @@
 ---
-title: Configuring Builds as Code with YAML in Azure Pipelines
+title: Configuring CI/CD Pipelines as Code with YAML in Azure DevOps
 layout: page
 sidebar: vsts
 permalink: /labs/azuredevops/yaml/
 folder: /labs/azuredevops/yaml/
-version: Lab version - 15.8.2
-updated: Last updated - 9/4/2018
+version: Lab version - 1.33.1
+updated: Last updated - 4/30/2019
 ---
 <div class="rw-ui-container"></div>
+
 <a name="Overview"></a>
 ## Overview ##
 
-Many teams prefer to define their builds using YAML (Yet Another Markup Language). This allows them to access the same build pipeline features as those using the visual designer, but with a markup file that can be managed like any other source file. YAML build definitions can be added to a project by simply adding their source file to the root of the repository.
+Many teams prefer to define their build and release pipelines using YAML (Yet Another Markup Language). This allows them to access the same pipeline features as those using the visual designer, but with a markup file that can be managed like any other source file. YAML build definitions can be added to a project by simply adding their source file to the root of the repository. Azure DevOps also provides default templates for popular project types, as well as a YAML designer to simplify the process of defining build and release tasks.
 
 <a name="Prerequisites"></a>
 ### Prerequisites ###
 
-- This lab requires you to complete task 1 from the <a href="../prereq/">prerequisite</a>  instructions.
+- This lab requires you to complete task 1 from the [prerequisite instructions](../prereq).
 
 <a name="Exercise1"></a>
-## Exercise 1: Configuring Builds as Code with YAML in Azure DevOps ##
+## Exercise 1: Configuring CI/CD Pipelines as Code with YAML in Azure DevOps ##
 
 <a name="Ex1Task1"></a>
-### Task 1: Configuring the Parts Unlimited project ###
+### Task 1: Creating Azure resources ###
 
-1. Navigate to your team project on Azure DevOps. Before digging into the YAML builds, you will want to disable the continuous integration trigger for the default build definition.
+1. This lab requires a deployment of the Parts Unlimited project out to an Azure app service. To do this, you will need to spin up the necessary infrastructure. Log in to your Azure account at [https://portal.azure.com](https://portal.azure.com/).
 
-1. Navigate to **Pipelines \| Builds**.
+1. Click **Create a resource** and search for **"web sql"**.
 
     ![](images/000.png)
 
-1. This project includes a default build definition, **PartsUnlimitedE2E**. Click **Edit** to edit the definition.
+1. Select the **Web App + SQL** option published by Microsoft.
 
     ![](images/001.png)
 
-1. This build is scheduled to run whenever a change is committed. We don't want to wait for this build every time there's a change, so select the **Triggers** tab and uncheck **Enable continuous integration**. From the **Save & queue** dropdown, select **Save**.
+1. Click **Create**.
 
     ![](images/002.png)
 
-<a name="Ex1Task2"></a>
-### Task 2: Adding a YAML build definition ###
-
-1. Navigate to the project files using **Repos \| Files**.
+1. Enter a globally unique name for the app service. You may find it easiest to incorporate your name, such as **"pul-yaml-johndoe"**. Select the option to **create a new** resource group named **"partsunlimited"**.
 
     ![](images/003.png)
 
-1. Add a new file to the root of the repository using **New \| File**. YAML build definition are simply code files you add to your project. They offer all the benefits of other source files.
+1. Select the option to configure the **SQL Database**. Click **Create a new database** and enter the name **"partsunlimited"**.
 
     ![](images/004.png)
 
-1. Name the new file **"azure-pipelines.yml"** and click **Create**. To make it more convenient to create YAML build definitions, Azure DevOps automatically creates a definition when you add this file to the root of your repository. The build definition is created in a folder that has the same name as the repository.
+1. Select the option to configure the **Target server** and click **Create a new server**. Enter a globally unique server name, such as **"pul-yaml-johndoe"** and provide admin credentials. Click **Select** to confirm the server settings.
 
     ![](images/005.png)
 
-1. Add the YAML markup below to the file and click **Commit**. This simply instructs the build to execute the echo at the command line so we can confirm it's all working. Once the commit has completed, it will queue a new build for this definition.
+1. Click **Select** to confirm the database settings.
 
-    ```
-    steps:
-    - script: echo hello world
-    ```
     ![](images/006.png)
 
-1. Select **Pipelines \| Builds** to navigate to the build hub.
+1. Click **Create** to create the resources. Note that you may need to create an app service plan first, if you do not yet have one.
 
     ![](images/007.png)
 
-1. The newly created **PartsUnlimited CI** will run using the YAML settings. Click the build to follow its progress.
+1. It will take a few minutes for the resources to provision, so you can move on to the next task.
+
+<a name="Ex1Task2"></a>
+### Task 2: Configuring the Parts Unlimited project ###
+
+1. Navigate to your team project on Azure DevOps in a new browser tab. Before digging into the YAML pipelines, you will want to disable the existing build pipeline.
+
+1. Navigate to **Pipelines**.
 
     ![](images/008.png)
 
-1. Track the build until it completes. Select the **Logs** tab and open the **CmdLine** task.
+1. Select the existing **PartsUnlimitedE2E** pipeline.
 
     ![](images/009.png)
 
-1. You can see where the script you defined earlier was generated and executed.
+1. From the dropdown, select **Pause pipeline**.
 
     ![](images/010.png)
 
-1. Close the task viewer.
-
 <a name="Ex1Task3"></a>
-### Task 3: Crafting sophisticated YAML definitions ###
+### Task 3: Adding a YAML build definition ###
 
-1. You can do virtually anything with YAML that you would do with the web experience. In fact, you can even export existing build definitions as YAML if you would prefer to manage them in code. Select **Builds** to return to the hub.
+1. Navigate to the **Pipelines** hub.
 
     ![](images/011.png)
 
-1. Switch to the folder view and select the **PartsUnlimitedE2E** build definition. Click **Edit**.
+1. Click **New pipeline**. We will use the wizard to automatically create the YAML definition based on our project.
 
     ![](images/012.png)
 
-1. Click **View YAML** to see the YAML export of this definition.
+1. Select the **Azure Repos Git** as the source hosting platform. Note the others supported.
 
     ![](images/013.png)
 
-1. Click **Copy to clipboard**. We'll take this as-is and use it for a YAML definition.
+1. Select the **PartsUnlimited** repo.
 
     ![](images/014.png)
 
-1. Navigate to the project files using **Repos \| Files**.
+1. Select the **ASP.NET** template as the starting point for your pipeline.
 
     ![](images/015.png)
 
-1. Open **azure-pipelines.yml** in the **Editor**.
+1. Review the contents of the YAML definition. It will be saved as a new file called **"azure-pipelines.yml"** in the root of the repository and contain everything needed to build and test a typical ASP.NET solution. Click **Save and run**.
 
     ![](images/016.png)
 
-1. Replace the contents of the file with those on your clipboard.
-
-1. Note that there is a comment block early in the file that reminds us that this definition is expecting some variables. The **SymbolPath** reference is coincidental (it's a literal needed for the build), but the **BuildPlatform** and **BuildConfguration** variables will play a role later.
+1. Click **Save and run** to confirm the commit.
 
     ![](images/017.png)
 
-1. **Commit** the change back to the repo. This will queue a build.
+1. Track the build until it completes. Click **Job** to see the logs.
 
     ![](images/018.png)
 
-1. Select **Pipelines \| Builds** to return to the build hub.
+1. Each task from the YAML file is available for review, including any warnings and errors.
 
     ![](images/019.png)
 
-1. Click the new build to follow its progress.
+1. Close the tasks view.
 
     ![](images/020.png)
 
-1. The build should succeed, but note that it reports that there were no tests. There should have been, so now we'll need to figure out why they weren't picked up.
+1. Select the **Tests** tab.
 
     ![](images/021.png)
 
-1. From the **Logs** tab, select the **Test Assemblies** task.
+1. The tests should now succeed as expected.
 
     ![](images/022.png)
 
-1. Note that there is a warning that the test assembly pattern didn't find any matches. Upon closer inspection, it appears that it was expecting a build variable for **BuildConfiguration** to be available, but since it wasn't, the platform simply used the text as-is. This was something we probably should have expected given the warnings in the YAML.
+<a name="Ex1Task4"></a>
+### Task 4: Adding continuous delivery to the YAML definition ###
 
-    ![](images/023.png)
+1. Now that the build and test processes are successful, we can now add delivery to the YAML definition. From the options dropdown, select **Edit pipeline**.
 
-1. Close the task view.
+    ![](images/023.png)
 
-1. Click **Edit**.
+1. Set the cursor on a new line at the end of the YAML definition. This will be the location where new tasks are added.
 
     ![](images/024.png)
 
-1. Select the **Variables** tab. Although the definition itself is in YAML, we can still manage things like variables and triggers externally.
+1. Select the **Azure App Service Deploy** task.
 
     ![](images/025.png)
 
-1. Use the **Add** button to add two new variables. **"BuildPlatform"** should be **"any cpu"** and **"BuildConfiguration"** should be **"release"**. Check the **Settable at queue time** options for each.
+1. Select the Azure subscription where you created the app service earlier. Click **Authorize** and follow the path to complete authorization.
 
     ![](images/026.png)
 
-1. Select the **Triggers** tab. Note that you can override the YAML settings and configure continuous integration like web-based builds.
+1. Enter the **App Service name** you used to create the app service earlier. Update the **Package or folder** to **"$(build.artifactstagingdirectory)/*.zip"**. Click **Add**.
 
     ![](images/027.png)
 
-1. Select **Save & queue \| Save & queue** to save the definition and queue a build.
+1. The YAML that defines the task will be added to the cursor location in the file.
 
     ![](images/028.png)
 
-1. Click the new build to follow its progress.
+1. Click **Save** to commit the changes.
 
     ![](images/029.png)
 
-1. When the build completes, select the **Tests** tab to confirm that everything has succeeded as expected, including the tests.
+1. Confirm the **Save**. This will begin a new build.
 
     ![](images/030.png)
 
+1. Return to the **Pipelines** view.
+
+    ![](images/031.png)
+
+1. From the **Runs** tab, open the new build.
+
+    ![](images/032.png)
+
+1. Click **Job** to follow each task.
+
+    ![](images/033.png)
+
+1. Expand the **AzureRmWebAppDeployment** task to review the steps performed during the Azure deployment. Once the task completes, your app will be live on Azure.
+
+    ![](images/034.png)
+
+<a name="Ex1Task5"></a>
+### Task 5: Reviewing the deployed site ###
+
+1. Return to the Azure portal browser tab.
+
+1. Navigate to the app service created earlier.
+
+1. Select the **Configuration** tab.
+
+    ![](images/035.png)
+
+1. Click the **defaultConnection** setting.
+
+    ![](images/036.png)
+
+1. Update the **Name** to **"DefaultConnectionString"**, which is the key expected by the application. This will enable it to connect to the database created for the app service. Click **Update**.
+
+    ![](images/037.png)
+
+1. Click **Save** to apply the changes.
+
+    ![](images/038.png)
+
+1. Return to the **Overview** tab.
+
+    ![](images/039.png)
+
+1. Click the **URL** to open your site in a new tab.
+
+    ![](images/040.png)
+
+1. The deployed site should load expected.
+
+    ![](images/041.png)
+