Azure Pipelines - Release

>> 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, and 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 and then we're going to look at release pipelines. So again, best place to get more information on this is the Azure DevOps services documentation, aka.ms/vst/azuredevopsdocs. Great place to look at that. So in the previous episode, what we did was we created a build pipeline, and 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 to the broker unit test. Check that code in, push that code into the repo that triggered the build, which then failed because I broke a test. Then in the meantime, I went back to that code, change the code back. So the test worked again, checked it in, and that triggered a build which succeeded, and I did this part off-air. What I want to do is show one more thing about build pipelines, and I want to talk about branching. Because so far, we've just been working with the master branch. So 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 AboutPageV1.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 AboutPage 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 AboutPage. Updated AboutPage text, commit all push. This push is add up to the branch. Then in the last episode when we push things to master, that trigger the build, we've now push 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, we create a pull request. So let's do a new pull request, and this is AboutPage 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 AboutPage V1.1, etc. I can assign reviewers. I'm not going to do that. I'm just going to create the pull request. 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. 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 a 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. 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. So either way, it 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." 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. Then vstoolbox.azurewebsites.net is production. At the moment, I haven't put any code up in here. I just created the app services. I'm going to call this stage test because what I'm going to do is create a release pipeline and that releases to test first, and then to production. 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. 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 Azure, to my Azure, username and 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. I said it was a Web App on Windows. Now which one? It's VS Toolbox Test. Now, then I come back to the Pipeline, and the first couple of times I tried this out I forgot to specify something in the Artefact, so I said, let's publish to Azure, but I never said what are we publishing, don't make that mistake. Let's click "Add an Artefact". 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. I'm going to select the YAML Build that we built last time, Toolbox DevOps Show, and click "Add". 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 too here, 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 request, I'm going to leave that disabled for now. Then what I also want to do is I want to create another Stage. I could create a new Stage and specify all the things, or I can clone this Stage because it's almost the same. Instead of saying copy of tests, 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. There's other options, I can pass in variables. I can say, how long to retain or release. There's all kinds of things I can do here. But I also want to look at 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. Let's say me. There's an option here to say that if you requested the release or deployment, you can approve it, so can approve your on stuff. Here, because I'm a glorious team of one, I'll make me the approver. The default timeout interestingly is 30 days. That 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. You want to see that certain load tests 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. 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. All right. Now let's save this. Now we have a Release Pipeline. Now, if we pop back to our previous example, where we merge 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. Then "Okay". 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. Stash that. I want to bring down Master. Because we did the pull request, so now I want to make sure that I have in Master the current versions. Now, what I'm going to do, I'm not going to work off a Branch, I'm going to work off Master. I'm going to check this in, updated, about page texts, not going to worry about my typos. Yes, I am because it's in perpetuity. All right, let's push this. Now, checking in this change into Master, which will kick-off a Build, and we're 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 is just been kicked off because the Build succeeded. 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 test, 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. 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. 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 tests to go. That's repeatable, and it happens the same way over and over again. 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. We should see the website. There's the website with the 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 e-mail 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 e-mail. I want to see what the Test results are. I want to talk to the Testers. 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", we'll take many of the Approval. I can add comments. I can differ for later, but because its all good, I'm going to approve this. 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's 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 what's discussing. Now we're just waiting for this to get sent to Production. That worked. Now, we come over to the Production site like that. There we go, and head over to the About page, and of course it's correct. Again, the docs here they are, Azure DevOps documentation, aka.MS/vst/AzureDevOpsdocs. Great place to learn how to do this. Start slowly, build some simple Build Pipelines, some simple Release Pipelines. Learn 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. We will see you next time on Visual Studio Toolbox.