 Joining me today on Visual Studio Toolbox is Tupelo, Mississippi's second most famous resident, and we're going to talk about DevOps and Azure Pipelines. Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me today is Mickey Gousset. Mickey, how are you? Hi, Robert. I'm excited. I'm very excited to be here. I've been trying to get Mickey on this show for probably years, and now that you are a Microsoft employee, and you're in town, today is the day. I am. I'm a DevOps architect on the Microsoft DevOps Customer Advisory Team, and I'm very excited. And you are from Tupelo, Mississippi. I am. Now, Robert, do you know what Tupelo, Mississippi is world famous for? We are a small 30,000-person town in northeast Mississippi. We get about 30,000 people a year that visit my town, half of which probably come from Europe. Yeah. It's the home of one of my favorite blues artists, Mr. Paul Thorne. That is true, but that is not why they are world famous. That would be the birthplace of the iconic Mr. Elvis Presley. That is correct. I did know that. Elvis was born in a two-room, not a two-bedroom, but a two-room house in northeast Mississippi. So they come, they tour his house, they tour his church, they go to the hardware store downtown where he bought his first guitar at age nine, that is still a hardware store, and then they drive up to Memphis, Tennessee to see Graceland where he got famous. Cool. But that's not what we're here to talk about today, is it? No, that's not what we're here to talk about. We're going to do some DevOps stuff. We're going to talk about Azure Pipelines. We are indeed. Do you know what Azure Pipelines are, Robert? I'm going to, I do, but I'm going to pretend I don't the purpose of the show. Okay. So I do know about DevOps. I know about continuous integration, continuous deployment, your CICD pipeline, and the Azure Pipelines the same as those? It fits into that story. Okay. Yes. So we have Azure DevOps, which used to be called Visual Studio Team Services, which is the Cloud version of what used to be called Team Foundation Server. So one of the different, one of the components of Azure DevOps is Azure Pipelines and it's been referred to by a lot of different names. They call it the build system. It's got build, it's got the ability to do build management, release management, all of those things, but we encapsulate that into what we call just Azure Pipelines in general. Okay. What's nice about Azure Pipelines is it works with a multitude of different languages. So we're talking Ruby, C-Sharp, Python. You can use it to deploy both on-prem or into the Cloud and you can target PAS, you can target infrastructure as a service. It's got multiple different options for being able to work. The goal being to be able to automate, do that whole continuous integration, continuous delivery to honestly build better software. Okay. Cool. Because the whole point of having a build system is because if you have multiple developers working on the same code, if you're not doing a daily build, doing a nightly build, running your smoke tests, running your integration tests, then you can run into a lot of problems farther down the road. You can have a lot of bugs that creep into the system. Once that happens, that's technical debt and other things you have to deal with at a later point in time. What's interesting though is you also need to look at your releases, not just your builds, look at the continuous delivery aspect of it. Because with continuous delivery, the point is you want to be able to release, and to say your dev, your QA, and your prod the same way, the same code every time. Right. If you're doing it manually, you might miss that quotation mark that you forgot to copy when you were copying over the line of code to push things out. Okay. Cool. Now, one of the things I like about Azure Pipelines is that we have the ability to build out these pipelines in a nice GUI interface, which I'll show you in a moment. But we also have the ability to do it with code. So we can write what's called a YAML file and actually write some code that stays with the rest of our code to be able to make our builds work. Yeah. I definitely want to talk about that when we get to that point. Now, the other thing I really want to point out real quick about Pipelines is it doesn't just work with Azure DevOps. It works with Azure Repos, which are the Repos and Azure DevOps. But they also works with GitHub. Okay. It can work with Bitbucket, it can work with a variety of different systems. So it's very nice from that standpoint, but what's really nice, what's really nice about Azure Pipelines is that, if I have an open-source project and it's a public open-source project, then I can get 10 free pipelines on the service to be able to do my builds for my open-source project, which can really speed up the build time for some of these projects that are out there. Cool. Let's see how it works. Okay. So way I got started is that I wanted to create a quick little test project to work with. So I use the Azure DevOps Demo Generator, which is a publicly available demo generator out there, which has a lot of different templates that you can work with. They've got ASP.NET templates, it's got Node.js, a lot of different projects you can use. These are some of our famous demos from Keynotes and launches past. Exactly. So I went with Parts Unlimited. Honestly, this is open for anybody to use, and all you have to do is come out here and give it your organization that you want it to deploy to, your Azure DevOps Organization, give it a name and punch the button, and Bob's your uncle, and there you go. Now, what that created for me out here was a Parts Unlimited team project in my Azure DevOps Organization. If you've not used Azure DevOps before, which I'm sure you have, but you have the boards area with a boards hub, which is where you can deal with work items. One of the nice things about the demo generator, it generates a ton of work items for you. So you can actually see how the work item system works, and it also generates code for you, so you can see how Repose works. But what we're going to work with is pipelines. So in the Azure Pipelines Hub, I've got my build section for building my code. That's the CI portion. I've got my releases section for doing the releases, which is my continuous delivery portion. We have a bunch of other features, libraries, and way to group servers, you might want to deploy to into groups, things like that. But if we just go look at the build, I've got one build here, and I just want to show you what this build looks like. Yay, look, I've got all green. If I go to Edit, this is the build system that we have in Azure Pipelines. So for example, right now I'm deploying the hosted build, meaning that I'm using a bunch of build servers that Azure DevOps has up in the cloud for me to use. I can use those hosted servers, I can use my own private servers, those are called private build servers, and those could be in the cloud or on-prem as well. Now the hosted servers are really nice though, because they have a lot of the things you need to do your builds already installed on them, the pre-software that you might need to make things work. So what you do is you select your pipeline, you specify where you want to get your source from, in this case I'm using repos, but as you can see I could be using Team Foundation version control or GitHub, or any of these options. Then you specify the agents that you want to use, these are the different jobs, I could specify multiple jobs, and then you have the specific tasks that you want to do in this build. This builds just doing a NuGet Restore, and then it's just doing a regular build on the solution, running some tests, and then publishing my artifacts out to a drop location where then I could use them as part of the release. The demo generator created that build for you, if you were creating the build from scratch, then you have to know how to select each of these things and what order they go in. You would kind of have to understand the basics of how your build would work. What you do is just come here and add different tasks, and there's different tasks for building, for doing tests, for maybe helping with deployment, and these are a lot of tasks that both Microsoft provides as well as the marketplace out there for other tasks as well. So yes, you do have to understand how what you're building needs to be built, and then you can add the things in here that you need. So you can add the different tasks, you can also have variables in your build process. So these are different things where you might want to be able to specify certain values that you then, you set the variable in the task itself, and then any time you need to change it, you can modify the variable here. In releases, that comes in very handy as well. You can triggers determines when you want to trigger, do you want to do continuous integration or not. So continuous integration being every time I check in, or maybe every time I do a pull request, depending on how you want to set things up, it can run certain tests to verify that everything looks good before it moves on to the next step in your process. Or you can even schedule them nightly build whatever you want to do. Then of course you've got different things where you can set like your build number, that kind of your build number format, how long you want to retain your builds, things like that. I'm not going to kick this off because it could take a few minutes to run. But what I will do is come out here and if you look at the results from one of these builds, then you can see that for each task, it breaks down for each task, what happened in each task, you can actually drill into each task and see the details of what occurred on that particular task. So if you've got errors in your build, this is where you would come to try to find the errors that were related to why your build failed. It's got a good summary overview where you can flip through here to see what's happening. It shows you the test information. So when your test ran, it shows you which one's passed, which one failed. Assume you had a test, right? Assume everyone has tests, right? You have to have tests. Then if you're doing code coverage, it has code coverage information as well. Okay. So that gets my code built, and then I store my code in a drop location. Since I'm building in Azure DevOps, it stores it in a drop location up in Azure DevOps. If I was building local, I could have maybe a file share somewhere that I might want to put those out. So that handles the CI portion of things. But then we have the CD portion. So you can set it up so that every time you check in the build occurs. Yes. Or you can schedule builds, or of course you could do them manually. But the beautiful things about the DevOps mindset is you have things happen automatically. So you can decide whether you want to turn on continuous integration, which is turned off by default, and have every time you check in a build runs, or you just do a nightly build based on the code that's been checked in. Correct. Okay. Then also you can just kick them off manually. Right. If you need to, whenever you need to. Okay. The second half of this whole process is releases. We need to release our code. So again, one of the things that the DevOps Build Generator did for me is create this a default release pipeline for me. So what this release pipeline is doing is I'm specifying the build that I want to pull from, and I could turn on continuous integration to where as soon as the build passes, it automatically starts releasing if I want to. What I have is different stages, different environments that I can release to. Is that typically done? It depends on the organization. I mean, you would release it to test. I presume. You might release it to test and then have tests that are run. Just because the build succeeded, it doesn't mean the app works. That is correct. So you want to have gates in place, gates in place to make sure that you're not just pushing out something all the way to prod, just because. Okay. So what we've got is different environments. Now, these are logical environments, so say like a Dev and a QA. You notice I've also got a production, but I don't have it actually linked up. This is because in this scenario, I manually pushed a production. Got it. So what happens is, this build runs, if I had continuous integration turned on, it would immediately push out to the Dev environment. If we look at the tasks that make up the Dev environment, since this is just a website, it just is doing an Azure deployment, an Azure App Service Deployee, and then it's setting some variables specific to the Dev environment. So it's setting some specific things related to the Dev environment. So this is just a web app? So this is just a web app, yeah. Parts unlimited is just a website app. And by the same token, if we go back to here, oh, went too far. If I go, wait, let me go back to my releases. See, this is the fun part. You can see that I've also got a QA, where I've got tasks in my QA as well that would deploy to the QA portion of wherever things are. Now I've got variables that I set based off of, I set the website name based off of whether I'm in the Dev environment or the QA environment or the production environment. So I've used these variables and I've set these variables in the different tasks in the pipeline to where then it goes, oh, you're deploying to Dev. Let's set these variables. Let's replace this stuff in app.config or wherever we need to make some changes. And what we've actually got here with this pipeline is if we go back to my actual release, right now we've deployed to Dev and it deployed perfectly, but we're waiting on QA. And that's because I can actually specify gates. So I can specify post gate conditions or post deployment conditions and pre-deployment conditions. So here in this pre-deployment condition, I've specified that someone has to approve it before it can go to QA. And I've got a lot of different options. I can gate off of maybe a webhook into something else or gate off of test completing. There's, you have multiple different options for how I want to gate. And then it just becomes a matter of, okay, well if you've gated, well then let's go look at that release. I would have gotten an email, which I did, and I can just come in here and say that I approve. Toolbox forever. And once I approve that, it will then start deployment into QA. Okay. So you have the ability to create these multiple pipelines, both for, you know, that can release into multiple different environments. So, and if you enable all of this up, we now have continuous integration. So when we're checking in, we're building our code. And then when we're building our code, we can have it automatically start going down whatever our pipeline process is to do delivery. Hopefully speeding everything up faster, you know, getting code out there faster, but also ensuring quality. That's the one thing I think a lot of times people don't realize is the quality aspect that doing this continuous integration and continuous delivery can give you. Right. So it really puts you in a world where you've got a work item, whether it's add a feature or fix a bug. You make the fix, you check the code in, and you're like, I'm done, right? And you walk away. But you're not really done because you're done with your code, which you tested locally, and it works locally with your current version of the code. But you check it in, might have broken somebody else's code, or somebody else's code might have broke yours. So the build itself may or may not work. If it does work, then all the tests run, then it gets deployed, but all of that's automated for you. See, just code all day long. It's whatever time you leave, you check in, you leave, right? And then all this work happens automatically. The dev guys or the QA guys come in the next morning, and there may or may not be a new version. If everything went well, that new version's already there, and they can proceed to testing. Nobody has to wait around and wait for somebody to do the release. Nobody has to go, oh, it's Wednesday? Oh, it's my turn to do the release? Oh, I forgot, right? So it automates a lot of this stuff for you and checks to make sure along the way that things worked, right? So QA gets in in the morning or you get in in the morning and there's no new version for them. It's because something went wrong in between you checking in your code and pushing out the new version to them. It's all automated, it's all logged for you and you may or may not get an email or text message at midnight telling you, depending on whether you want to. But you certainly could, right? That is correct. Cool. That is all correct. And it's pretty easy to use. It's pretty easy to use. I mean, as long as you understand the general process, getting everything set up is pretty easy to do. And you don't have to be part of a massive team. You don't even have to be part of a multi-developer team. I think even if you're writing just code for yourself, just an app you use yourself, you should run it through the full DevOps processes to get better at building software yourself so that you can, even if it's just for you, it makes you better at delivering software. Now you have the skills that you can bring to work or to the multi-developer applications as well. I agree, 100%. So let me take it one step further. All right. So I've shown you the gooey way of building out these pipelines. But one of the things that people ask for, especially with build systems, is a way to track the versions of their build pipeline with their actual code. So the way we do that is with what's called a YAML file. YAML. YAML. Which stands for? It depends on who you ask, but according to my research, it stands for YAML-Ain't-Markup Language. So it doesn't stand for yet another Markup Language? That's what I've been told. So if you go to yaml.org. If you go to yaml.org, what do they say? Let's see, what do they say? Do they have YAML-Ain't-Markup Language? There you go. A myth busted. But yaml.org is a great place to go to get some basic information on yaml in general. And there's yaml, you know, everybody, you can define how you want your yaml to work, you know, everybody can define it differently. But essentially what you have is structure that's enforced through indentation with spaces, not tabs. Right. And key value pairs. Which is one of the first things you use when working with yaml, that that matters greatly. Yes, it does. I found that out the hard way. It's very difficult often to just copy and paste yaml code in because this code, you copy it in and it winds up putting tabs in and then it doesn't work and you have no idea why. Exactly. Or so I'm told. It's basically a human readable data serialization language. It's based off of JSON, obviously, as you can tell. And if we go and look, I love, by the way, our documentation. And if you go and look at the documentation for pipelines, they actually have a create your first pipeline documentation section with a lot of different selections for you. So we've provided a bunch of the code you need to get started with creating your first pipelines using yaml. So what I did is I took the pipeline's JavaScript one and I forked it into my, so it's on GitHub, Microsoft Docs, Pipeline JavaScript. And I forked it to be just have my own version of the project. And it gives you all of this out of the box, including a starting pipeline's file. So I'm now working with GitHub as my repo. So I'm able to take this repo and I'm able to clone it down and start working with it. And my tool of choice for working with pipelines or yaml files is Visual Studio Code, love Visual Studio Code. One of the nice aspects of Visual Studio Code, if you're working with Azure Pipelines, is the Azure Pipelines extension. Now, what we've got here if we look at this very simple pipeline is we're basically saying, this is the pool that we, this is the image that we want to use. So this is the Linux image we want to use when we do our build. And we're saying use the node tool task and just for grins we'll change this to be 8 instead of 10. Just to make a change. And you know what, I really want this to show up with a better name. So I figure there's a way to do display name. So you notice I got to space it in twice. But then if I do control space, I get IntelliSense. And I can say, well, I want to do display name and this is just going to be the node tool. Now, this is a task that I'm going to run, one of those tasks. Remember when I click the plus sign in the GUI, this is using one of those tasks. This is actually running a script. So it's going to say just run npm install and then npm test. And I'm using some other tasks to publish out and publish the code. Now, if you build a pipeline using the visual designer, is there a way to convert it over to YAML automatically? Yes, well, yes, there is. Well, not to convert it over automatically, but what you can do is if I go to this build, and I go to edit. What I can do is I can try to view the YAML for this entire build. Okay, well, there you go. But sometimes the build may be doing things like putting in setting certain variables for me. But then I have to make sure I add that to my YAML file. But one of the ways I've taught myself YAML and to build out some of these pipelines is to use select a particular task you want. And you can view the YAML just for that task. Okay, cool. So I build it first in the GUI to understand and then I can transpose the code over. And then of course, once we've made these changes in Visual Studio Code, we can just, and we save those changes. Then we can just come back over here and commit that locally, like a type. And then once it finishes doing that, we'll just push it on up to, or push it back out to GitHub. Now what I've done in GitHub, in my repo in GitHub, is I've gone to the Marketplace and I've grabbed Azure Pipelines. And I've gone through a configuration where I've set up my team project in Azure DevOps to be connected to my GitHub repo. So that now, since there was a check-in to my GitHub repo, it will have kicked off a build. And if we come over here to builds, come on, you can do it. You can see there's my change node to eight. Yeah. And it's kicked off that build process. How does it know to read that YAML file? And how does it know that that YAML file contains the build information? I came into my Azure DevOps team project and I created a new pipeline. And I pointed it to that YAML file. Got it. And by pointing it to that YAML file, you can see there, I added a node tool. Now, what's really cool about this is that one of the things you have to remember is that you can come in here and, it's not what I meant to click, but you can come in here and you can modify the triggers, you can use variables. So you have the ability, just like we had variables over in the build GUI and in the pipelines, I can have different variables that I can access, I can set the trigger, I can point to a different YAML file if I need to. So if I ever needed to, say, change the YAML file I was working with, I could point that to a different, to a different area. So would you agree that if you're just getting started with these, you should use the visual designer and then once you understand what's going on, then you can go over to YAML or would you start with YAML? The answer is, good consultant answer, it depends. For me, it was easier to get started with the GUI. For a lot of people that maybe are used to using other build systems, like maybe Travis or CircleCI, where they use YAML files as well, then you might have a little- Or if they're familiar with the YAML files already, because that's what Helm charts are written in if I'm not mistaken. Helm charts used in deploying containers. And what this does though is think about it now, I've got my build. And my build is now, or the description of my build is now being version controlled with my code. It's following me around when I branch. So I'm able to track the changes to my build in addition to the changes in my code. Now, this leads to the question, can I do this with my releases? And the answer is not yet. Okay. Now, but the product team is aware of it and they're actually working on it. And if you go to microsoft slash azure-pipelines.yaml, you can actually see the design docs that we have out there. And kind of what the plan is, and so they're aware that people want that feature. Very nice. So they're working on it. But it's, and you know, I'm working closely with some of the open source projects on GitHub to help them with pipelines. And it's just, it's a very, very solid, robust product. So I really hope people will check it out. Very nice. So that was a great overview of the pipelines. I think we saw how easy they are to use. We'll put in the show notes, number of resources pointed to the docs and the demo generator and a couple other things. And people should just absolutely get started using this stuff and learning how to apply the DevOps practices and their development. Absolutely. All right, so thanks a lot, thanks for being on the show. Thank you, this was so much fun. And we will see you next time on Visual Studio Toolbox.