Defining tasks in YAML - Azure Tutorial

- [Instructor] As I mentioned earlier, tasks are the building blocks of your pipeline. You could think of a task as a package script, a procedure, or command that ultimately produces some kind of an artifact at the end. If you had an ASP.Net core application for example, you might have at minimum four tasks, restore Nuget, test, compile, publish, et cetera. Let's look at a basic set of tasks here needed to build an ASP.Net core application. Suppose I had this application then what kind of tasks would I need? Well, the first thing I'm going to do, and remember we're starting from a completely torn down brand new VM, the first thing I have to do is get the code on the box. So, I might run a git clone command, to get the source code locally. Then I might run a .Net restore, to install Nuget packages. Then I might run some kind of a build command with flags, such as setting the configuration to debug, which I'm doing here. Then I might run my .Net tests and I want to test my code and make sure it works. And, lastly, I will publish this application. Now, if anything fails along the way I want the process to stop and I want it to report a failure. Let's go ahead and create a simple batch file and run this, as if it were a pipeline, and see how it works. As you can see, this is a starter .Net core application, and I created a simple build script called build.bat. I put the .Net restore, the build script, the tests, and the publish in here as well. Let's go ahead and run this script and see what happens. I type build.bat, I see that it runs through the restore, the tests, the compile, and everything looks good. Just to be sure that we did all this correctly, let's go ahead and break this script. So, on the bottom on startup.cs, I'll just put some gibberish down there, and then ctrl+S to save. And I'll run this script again, to see what happens. As you can see, the application doesn't compile because it's got a compilation error in it. Now, the only way that I would know this failed is if I sat here and watched it. This is fine when there's a couple of classes but, when you get into hundreds and hundreds of classes you're not going to sit and watch this. Essentially, what I've done here is create a very simple build pipeline with tasks, in this case four tasks, restore, build, test, and publish. Now, lets look at how I can build this in YAML and do the same thing with this code. Let's go ahead and add a pipeline file with tasks defined, in this code base. If you have access to the example files, in this project, you can go ahead and open the Azure DevOps CI, from this chapter, from this video. And you can go ahead and right click on the build folder, click Add, New Item, go down to Text File, let's create a file called build-pipeline.yaml. Now, you should already be familiar with YAML, if not, know that YAML has some very specific requirements, about spacing, that make things work. Now I'ma go ahead an specify a trigger, for this pipeline, and that is going to be the master branch. Then I'll specify a VM pool, which is going to do the actual building, remember this gets spun up and destroyed with each build, and we'll do this on Ubuntu because it is .Net core, it can be built on any environment. Then I'll define my steps, this is where my tasks come in. The first one is going to be a script, which is just going to echo out, "Hello world." Then I will set the display name for that script to 'Run a one-line script', which is what we just did there. Then let's go ahead and add another task, in this pipeline, we'll run a multi-line script. So, I'll go ahead and put the pipe on line 11, on line 12 I'll say, "echo Add a multiline script". Then I'll go ahead and 'echo' and 'One more'. And I'm going to need to space these in two more times, for the YAML to not complain. Then I'll go ahead and set the display name to this, on line 14, to 'Run a multi-line script'. I'll save that build script. Now, obviously, this isn't compiling code or doing anything that that batch file did. What we want to do here is demonstrate how to create a pipeline YAML file, check it into our code, and have it versioned along with the source code. This is why many people prefer to do this, versus using the classic experience, this actually versions our build script with our code. Now I'm going to go to my Team Explorer, let's go ahead and check this change in, this new build-pipeline file. I'll add a comment, "Added build-pipeline.yaml", I will commit that change, and I will sync it up to my server. And now let's switch over to Azure DevOps, and see it run. Here I am, back in Azure DevOps, and I've deleted any pipelines that I created earlier, and I'll go ahead and click 'Create Pipeline'. And, instead of using that classic editor, like we did before, I'm going to actually just go ahead and pick the repo, select that repo. And I'll scroll down to 'Existing Azure Pipelines YAML file' and what's cool here is the path will actually detect that YAML file for me, I don't have to go search it out, or type it in. I'll click continue and there's my script, and let's go ahead and run it. And I'll go ahead and click into this job while it runs. But, if you notice now, here is the output from our job, you see that I checked out my code, which is on that brand new VM, then I have my running one line script, where I just did a very simple echo, which is right here 'Hello world'. Then I did my multi-line echo 'Add a multiline script, One More' and then it finalized, tore down the VM, and finished everything it's doing. Now we can make this script do something a little bit more useful than this. But at least now you know how to check in this YAML, sync it with the code. So, now you might be wondering what happens if I make a change to this script? Let's go back here and say, v2, v2, will it automatically update? I'll save that. Go ahead and, "Added v2 to our build script", commit that, sync, push. And I'll go ahead and alt+tab over to the other browser. If I go back to Pipelines, look at it, it's already running. So, I updated my build script, checked it in, and because I set up that trigger, it's already rerunning the script with the new v2 in it. And, if I look at the output from this job, you'll see that it's actually going to say v2 in here. So, you could see how powerful it is when you can actually check in a build script, with your code, have it automatically compile your code and run everything. As we get going, we'll talk more about some of these tasks and doing some more relevant things, other than just echoing out to the console. But now you at least know how to create a YAML file, and check it in, and watch it build.