 On today's Visual Studio Toolbox, part two of our two-parter. We're going to look at release pipelines and continue to see how you can deliver more value to your customers more frequently and more efficiently. Hi, welcome to Visual Studio Toolbox. I'm your host Robert Green. In this episode, we're going to continue our two-part look at how you can start adopting basic DevOps practices. We're going to focus on pipelines. We created a build pipeline last time. Today, I want to show one more thing about build pipelines. Then we're going to look at release pipelines. Again, the best place to get more information on this is the Azure DevOps Services documentation, aka.ms forward slash VST forward slash Azure DevOps docs. Great place to look at that. In the previous episode, what we did is we created a build pipeline. That build pipeline waits for a machine to become available, downloads the latest version of NuGet, restores the packages, builds the solution, runs the unit tests, and then publishes the build artifacts, which is the thing that you built so that it can later on be deployed. We saw that we ran one of these, it took about a minute and a half. Then I went into Visual Studio and made a change that broke a unit test, checked that code in, pushed that code into the repo, that trigger to build, which then failed because I broke a test. Then in the meantime, I went back to that code, changed the code back, so the test worked again, checked it in, and that trigger to build which succeeded. I did this part off-air. Well, what I want to do is show one more thing about build pipelines. I want to talk about branching, because so far we've just been working with the master branch. I'm going to come into Visual Studio and I'm going to, in the master branch, I'm going to create a new branch, and I'm going to call it about page V1.1. It's off of master, and I'll create that branch. Then what I want to do in this branch is make a change to the about page, and let's say provide more additional information. Perfect. Now, I'm going to check this in to that branch, because this is V1.1 about the about page, updated about page text, commit all push. This pushes that up to the branch. Then in the last episode, when we push things to master that trigger to build, we've now pushed things to a branch, which does not trigger a build. The reason it doesn't trigger a build is because we come in here and we edit this. There we go. Because this build gets triggered when we check into master. Now, you can, if you want, have this build triggered when things are checked into branches, but the default is that it's only triggered when it's checked into master. Now, that means that if we come over to here and to our repo and we create a pull request, so let's do a new pull request, and this is about page V1 into master. You can do this from inside Visual Studio. You can do this in Azure DevOps Services. Either way, I'm going to call this about page V1.1, etc. I can assign reviewers. I'm not going to do that. I'm just going to create the pull request. Okay. Then I can approve it. I can reject it, etc. I'm just going to approve it, and then I'm going to complete the PR. I can delete the branch if I want. Complete the merge. I have approved the PR. That code gets checked into master, and now you might expect a build to be kicked off, and indeed it is. At this point again, we could sit here and wait for the minute and a half. We can look at some additional information. We can view reports on pipelines. We can see how often this is building and failing. It's worked two out of three times. There's a whole bunch of information that you can get here. But I think what we'll do at this point is we'll just let this go, and then in the meantime, we're going to build a release pipeline. There are a couple of ways you can build release pipelines. You can come into releases and create the release pipeline from here, what you can also do is go into the repos, go into your repo, and you can select to set up a release from here. Either way works. I'm going to go back to doing it from here. So we'll go to a release, and I'm going to create a new release pipeline, and the release pipeline says two questions. What are you releasing and where is it going? So the first question you get asked is where is it going? I could do an Azure App Service deployment. I can do a bunch of things to Azure. I can do an IIS website with SQL Server. If I keep scrolling down, there's IIS without SQL Server. There's a whole bunch of options here. You can get more in the marketplace. I'm going to deploy to an Azure App Service because I have created a couple Azure App Services. So I've got VSToolboxtest.azurewebsites.net. That is a place to test the application, and then VSToolbox.azurewebsites.net is production. At the moment, I haven't put any code up in here. I just created the App Services. Okay. So I'm going to call this stage test because what I'm going to do is create a release pipeline that releases to test first and then to production. Okay. Now the question is what are you releasing? So if I click one job one task, I said that I was going to deploy to Azure. So the question is what Azure? So I will select one of my Azure subscriptions. So I'll choose this one. Now I need to authorize, I need to say that from Azure DevOps Services, I can go and talk to my Azure. Use your password and of course now tokens come down, things are configured. It takes a little bit of time. You'll have to do this once per project. So the next time I create a pipeline on this subscription, everything will already be on my computer to enable me to talk to Azure. So I said it was a web app on Windows. Now which one? It's VS Toolbox Test. Okay. Now, now to come back to the pipeline. The first couple of times I tried this out, I forgot to specify something in the artifact. So I said, let's publish to Azure, but I never said what are we publishing? Don't make that mistake. So let's click add an artifact. You can base it off a build, you can go directly to the source code. I'm just going to do it off a build, and I'm going to select the YAML build that we built last time, Toolbox DevOps Show, and click add. Okay. Now, look at a couple options. If I look at the trigger, the continuous deployment trigger, just as when we built the build pipeline using the classic build process, we had to enable continuous integration. So to here, do we need to enable continuous deployment? Meaning that after the build succeeds, we will take what got built and send it up to Azure. You could also do it on pull requests, I'm going to leave that disabled for now. Then what I also want to do is I want to create another stage. So I could create a new stage and specify all the things, or I can clone this stage because it's almost the same, and instead of saying copy of test, I'm going to call this production. Then the only thing here that's different, same subscription, but I want to deploy to VS Toolbox which is the production site. Okay. There's other options, I can pass in variables, I can say how long to retain a release. There's all kinds of things I can do here. Okay. What I also want to look at are the pre-deployment conditions and the post-deployment conditions. I don't want any conditions on test. The thing built, send it to test, test can start working on it. But before we go to production, I want to require approval. So let's set pre-deployment approvals to enabled, and let's say me. There's an option here to say that if you requested the release or deployment, you can't approve it, so you can't approve your own stuff here because I'm a glorious team of one, I'll make me the approver, and the default timeout interestingly is 30 days. Seems a bit long to me, I would probably make it earlier, but that's okay. You also have the ability to define gates if you have more than just approval, one person's approval is required. So you want to see that certain load test passed or certain statistics that you want to be met, certain conditions that you want to be met, you can learn more about that here, but it's really more of, you can set a particular bar and unless the application meets that performance bar or security check or something, then and only then can it be deployed. So I set a pre-deployment approval on the way in, and you can also set deployment conditions on the way out. So now let's save this. Now we have a release pipeline. Now if we pop back to our previous example where we merged the PR, that kicked off a build. Okay, perfect. All right. Now what I want to do is, I want to create, well, I have a pipeline, we have a pipeline that's created that's automatically going to run if we do another build. So let's go do one last build. Okay. So let's make yet another change here. Actually, let's not do that because I still am on the about page. I want to bring down master. Yeah. Stash that. I want to bring down master. So I want the little, because we did the pull request. So now, I want to make sure that I have in master the current version. So now what I'm going to do, I'm not going to work off a branch. I'm going to work off master, and I'm going to check this in, updated about page text, not going to worry about my typos. Yes, I am because it's in perpetuity. All right. Let's push this. So now, checking in this change into master, which will kick off a build, and we are not going to sit here and watch that build go. So let's fast forward until this build completes. Fantastic. The build worked, which should kick off a pipeline. There it is. Release one has just been kicked off because the build succeeded. So what happens is we're now going to deploy that to Azure. Again, you're starting to see why this is beneficial and how this helps you deliver value more consistently, because all of this is automated. The idea of building, running the tests, taking what got built and deploying it to Azure. In our case here, we're just taking a simple app and putting it into an Azure web app, but you can imagine that for testing, you might have an ARM template that not only puts the app up there, but creates a new copy of the database, maybe populates it with some sample data. There's a lot going on. Do you want to have to manually do that over and over again? No. What you want to do is work, work, work, and then when you're done with your code, you check it in, you go home. The build works, the deployment works. Whether it takes 15 minutes or three hours, who cares? The next morning, test comes in, that application has been deployed, it's all ready for test to go. That's repeatable and it happens the same way over and over again, and that's the benefit of these pipelines is to get repeatable, reliable things happening automatically so that you make a change, they test. You make a change, they test. You do that over and over, then you release and then you do that again in the next sprint. In the meantime, this has succeeded. It has deployed this to test. Let's see if that's true. Let's refresh here and we should see the website. There's the website with of course the latest version. Now, in the meantime, there is an approval pending to send this to production. Again, if we go into mail, I see that the build worked and there is pre-deployment approval. Me as the approver, I get an email telling me that we will go to production when I approve. Now, what is the process for me to approve? It's probably more than I got an email. I want to see what the test results are. I want to talk to the testers. We need to whatever process there is. Let's say that's all happened. Again, I can do this from the mail, I can view the approval from the mail, I can come in here, click pending approval will take me to the approval, I can add comments, I can defer for later but because it's all good, I'm going to approve this and what that does is, it kicks off the process of sending this to production. This may take more time, it may take less time in the test. It may take more time because you're creating a new version of the database, you want a clean environment in production, you're probably not wiping out all the data. It may actually take less time, although you may then have a series of tests that occurs to see if we literally roll this out. There is canary deployment, blue-green deployment, there are some techniques you can use to roll out the changes bit by bit rather than just have everybody use the new version, only to discover then that there's a mistake, a bug or something got wrong, there are ways to roll that out beyond our scope here, but worth discussing. Now we're just waiting for this to get sent to production, that worked and so now, we come over to the production site, look at that, there we go and head over to the about page and of course, it's correct. So again, the docs, here they are, Azure DevOps documentation aka.ms forward slash VST, forward slash Azure DevOps docs, great place to learn how to do this. Start slowly, build some simple build pipeline, some simple release pipelines, learn it at the cadence that makes sense for you, and start adopting the DevOps practices to be able to shorten your release cycles, better value for the customers, better world for you as the developer. Hope you enjoyed this and we will see you next time on Visual Studio Toolbox.