 Now, without further ado, we have here my colleague Zach about talking about DevOps for the.NET Engineer. Let's go to him. Hey everybody, my name is Zachary Deptawa. I'm a Cloud Advocate for Microsoft, and I'm excited to be here today. I'm talking about DevOps for.NET Core Devs. So let's just jump in. So what is DevOps? We've often thought, do we actually need DevOps? Is it a question of, is this something that we should even be focusing on now or in the near future? Well, we know now that you absolutely need DevOps. It's critical for businesses to innovate at the speed necessary in today's world. If you ask people, what is DevOps? If you ask five people, you'll probably get 10 different answers. So I can tell you what Microsoft's view of DevOps is. DevOps is the union of people, process, and products to enable continuous delivery of value to our end users. Notice I didn't say continuously deliver code. I said continuously deliver value, because if I just continuously deliver code, I can push it up in a source control, but I end up with a mountain of code somewhere. Unless it's delivering value, it's not really worth anything. So why is DevOps important? This is a big one. So if you're not currently using DevOps best practices, I can guarantee you your competitors either are or they're going to be very soon. So what that means is your competitor will be able to out-innovate you, they'll be able to do things at a much quicker pace than you can, and that might make you obsolete, and nobody wants to be obsolete, believe me. All right. So we always thought about this DevOps thing, right? We've got some manual processes. We're going to start to automate them. Things are feeling good. It's kind of a theory right now. Let's get things going, but now we have actual data. We can see the empirical data that says that companies that use DevOps actually innovate much faster than companies that don't use DevOps. It's not just by a little bit, it's by a lot. So when we think of DevOps at Microsoft, there's really three pillars that you need to pay attention to, and number one being people, number two being process, and number three being products, and we'll dive into those a little bit here. So admittedly, the hardest part of all of this of adopting DevOps best practices, in my opinion, is the people, and people they're averse to change, but not only that, you have to have this idea of continuously delivering value to your end users. From the very top of your organization to the very bottom, everybody has to be in line saying, yes, we want to continuously deliver this value to our end users, and that's really going to be the hardest part is making that shift. The process, now that's a little bit easier because really all the processes is finding something inside of your organization, inside of your team that works for you, that allows you to innovate quickly, but also allows you to maintain a high standard of quality for your applications. So that's probably the easiest of all three of these. Now let's talk about the products. So this is where you're going to find things that will help you use the DevOps best practices and methodologies. You need products that will help you plan and track, things like work items, bugs, impediments. You need things that are going to allow your developers to push and pull from source control, but not only that, that will tie back to that planning and tracking. So you can see where your work is actually making an impact. You also need something that's going to bundle up your code for you automatically. So your dev should be able to push their code for testing and have something fire off that's going to bundle that up and push it out into a testing environment for you right away. After you have everything into production, it doesn't stop there because you need to monitor and watch what's actually happening inside of your application. You need to know, is your application up? Is your application down? How are the response times within your application? You need to be able to see what your users are actually doing inside of your application. I don't know how many times I've talked to clients that say, we built this app to do this thing, but our customers are using it in a much different way than we thought that they were going to use it. So what that data allows you to do, is you can look and say yes, we're absolutely delivering value and that's great. Now we can double down on this and we can move forward in our next sprint and do way more cool things for our end users that will deliver value. If you're not delivering value, that's awesome too. You see that data, so you can pivot and make sure you deliver value on the next sprint. So all of these things, there's a ton of tools that can do all of these things, and these are all great tools. You can pick and choose these tools that will fit what you're doing. You have to make sure these tools can communicate, you have to make sure that there is no problem with that communication, and you have to make sure that it's set up accordingly and they work great, or you could replace all of these things with something like Azure DevOps Service. You can target any language, targeting any platform using Azure DevOps, and that's what we're going to talk about today. So what is Azure DevOps? Well, at a high level, it's a suite of five products. Azure Boards being the work item, task tracking management, you can track bugs, impediments, features, things like that. Azure Pipelines being the Git repository system for private Git repos inside of Azure. I'm sorry, Azure Pipelines being the CICD portion. This is the build in the release portion. This is the automation. Azure Repos being the private Git repository portion. Azure Test Plans is the testing infrastructure inside of Azure DevOps, and Azure Artifacts is the artifact repository inside of Azure DevOps. So that's great. That's a ton of talking. I got it out of the way as quick as I could. Let's jump into a demo and see this in action. So what you're looking at here, this is a.NET Core app that I have deployed. It's an actual app that's running. You can actually go to that if you want to. But what it's doing, this is an app that simply tracks my exercise and it tracks my nutrition for me. But what I noticed, actually what my co-worker Abel noticed, is that for some reason, we're tracking the color of our food, and honestly, we don't care about what the color of the food is, we just care about the important information. So we have this board here inside of Azure DevOps. This is our.NET Conf demo project, and this is our board, and you can see our tracking here. We have in sprint, a swim lane, we have a super-duper important swim lane, and you can see we have a bug here for food tracking should not track color. So this is really awesome. I'm actually hosting the code inside of Azure Repos here. So what I can do, I can click this little button here, create a new branch. I'm going to call this food color tracking, if I can spell, there we go. It's going to be based on the.NET Conf demo repository and the master branch. What's really awesome is because I built it from that work item from that bug, it actually links right to it. So I'm going to create this branch and it's going to link from my work item to that branch. So now on this branch that work item is there. So now I have a new branch, food color tracking. Let me drop over to PowerShell, and this is just a normal Git stuff that I'm going to be doing. I'm going to do a Git pull because I just created a new branch. I'll do a Git, if I can spell. Oh my goodness. Okay. Check out and let's not that. Okay. Git. I can't spell today. Okay. There we go. Now we're back on track. I checked out the food color tracking branch, and so now that I have that checked out, let's actually go edit the code. So I don't care about this color field in my database. I'm going to delete it inside my SQL file here, and I'm going to save that. I need to comment some stuff out here really quickly. I don't need these things. Okay. I'm also going to comment out here as well. Let's get this commented out. That's not necessary. All right. So now that I've made these changes, I'm going to save this. If I go back over to my PowerShell, I see that I've changed those three files. So I'm going to do normal commands, a Git add. I'm going to do a Git commit dash M, and this is just going to set a commit message for these changes, food color tracking removed. I'll do a Git push. So what this is doing is I'm actually pushing the code that I just changed into my food color tracking branch into Azure DevOps repos. So now if I go back over to my repository and I refresh, Azure DevOps, the repos, it actually saw that I updated my food color tracking branch, and it says, hey, you just updated this. Do you want to create a pull request? Well, if I wasn't done with my work, I wouldn't create a pull request, but I am done. This is all the work that I need to do. So I'm going to click create a pull request. It pops it up for me automatically. I'm going to be merging food color tracking branch into master. That's great. The title and description are pulled from my commit message and you can see that my food tracking should not track color bug is actually attached to this pull request. I didn't have to do anything and you can see my changes here that I made. Everything looks good. Let's create this pull request and boom, I've got a pull request. I can check out the files here and take a look, but not only that, I can make comments. I can say inline, this is the best code I've ever seen, which is totally true. I can hit comment, there's the comment inline, and now if everything looks good, I can go ahead and approve this. Now in the wild, you probably don't want to approve your own pull requests, but for the purposes of this demo I am. So what's really awesome is inside of Azure DevOps, I have a build and release pipeline, and I have it set for continuous integration. You can see this little blue here. That means that it saw that I made a change in my master branch and it kicked off my build automatically for me. This is happening in real time. We're actually watching these tasks run in real time. But even after the fact, I can drill in and get a look at what happened if I need to. If I need to go back for troubleshooting or just want to see what happened. While this is running though, let's take a look at what a build is actually comprised of inside of Azure DevOps. All right, here we go. So this is a build. You can see that we're getting the source. This source we're pulling from the Azure repo that I have, .NET Comp demo from the master branch. I could pull it from another source if I wanted to. Also, this is an agent-based task runner. So what's happening is I'm running tasks on an agent. These are the tasks that I'm running. But what's really cool is you can use a hosted agent that's hosted inside of Azure, or you can run an agent anywhere you want to run it. I'm actually running my agent on my demo server, and that's just something that you can do if you'd like to do that. But you can see because this is an ASP.NET Core app, I'm using NuGet, building the solution, testing my assemblies, copying my Dacpack, and I'm going to publish this to an artifact. This artifact is what will be used in the release, and you can see my build finished. So let's go ahead and take a look at this artifact real quick. So now that the build finished, here's the artifact. I've called it Drop, and you can see I've got my Dacpack, and I've got my web app.zip. I've got everything that I need for my release, but not only that because I have continuous integration and continuous delivery set up here, it's already kicked off my build into my development environment, and that is so powerful. I didn't have to do anything besides make that pull request and merge it. So let's take a look at releases real quick. So the way that I view releases, you can set up stages and such that you have one for each environment. So I have a development environment, a staging environment, a production environment, but you could do this in any manner that you want to if you have a different way that you like to set that up. You can also have stages that run in parallel with each other if you need that. You can see that we're using the artifact that was built, and also I can drill in here, and just like my build, I can watch this happen real time or go back and look at the logs if I need to, while this release is happening though, let's take a look at how a release is created and how a release is set up. So you can see that each stage has jobs and tasks, and for each of my stages, they all look the same, but it's the same set up for my build. So this is a task runner that runs on an agent, it can be hosted in Azure again, or it can be hosted on an agent on a server like I have here for my demo. But I'm deploying my Azure App Service, deploying my database and running Selenium, and that's the gist of my releases. Let's take a look and see where we are. Okay. So my release finished to development, but you notice it's blue here, it's not green, it's kind of weird, right? Let's take a look at what's going on. So I set up a post-deployment approver required. So now that this has kicked off, it's done my development deployment. I have an approver that's required to say, yes, everything looks good, I've tested it out. Let's go ahead and roll over to our staging environment. So I'm an approver, so I'm gonna go ahead and approve this. I can say, looks good to me, approve. I could also reject if I wanted to, but everything looks good. So theoretically that should have kicked off my build, right? Let's take a look. I mean, I'm sorry, am I released to staging? But it looks like it's hung again. So what's going on here? I set up a pre-deployment approver as well. So yes, someone that looked at development, made sure everything was fine, they were able to approve that, push it over to staging, but now someone from staging needs to go and take a look before it blasts that code into my staging environment. So whoever is managing that environment can go and say everything looks good, but not only that, if everything looks good, they can also defer the deployment for later. So say somebody like me decides I wanna push code at 5 p.m. on a Friday, which is not the best idea. Well, it can roll out to development, I can even accept that in my post-approver acceptance here, but it won't blast into another environment until somebody from that environment can take ownership and accept it. So that's really awesome. I'm just gonna go ahead and approve this though. And now it's in progress and it's rolling into my staging environment. So you can also set this up to where it's manual only, you don't have to do an automatic release if you don't want to, but that's just how I have this configured. So this is all really cool, but I wanna show you kind of a neat trick here. And actually, you know what, let's make sure before I do this, let's make sure that my changes are working. There we go, the color field is gone. So my changes look good, not only do my changes look all right, but if I go back to my boards, that bug that I was tracking that I opened this branch for, because the branch closed in that pull request, it actually resolved this bug for me. I didn't have to come here and do any of this, it just moved it right on over. So that's awesome and it's also tracking that. If I drill down into this bug, you can see that it actually tracks what happened with this work item. And so now that looks all great, but let me show you something awesome. So I'm just inside my Azure portal here and I'm going to click create a resource and I can click on DevOps project. Now what this does is this actually scaffolds out an entire DevOps and Azure DevOps project for you. So you can see all the different languages here that we have built in, you can bring your own code if you'd like to. I'm gonna click .NET and ASP.NET Core. I'll add a database. Let's go ahead and use Windows web app and let's name this .NET comp demo nine. We'll go ahead and choose an organization that I have access to and I can change the location here. Let's go ahead and put this in East US. There's also some additional settings that I can set. I can change where my application insights are and I can change where my database lives as well. I'm gonna put them all in East US just because and here we go. I can click done. And now what this is doing is super powerful. This is actually building out my Azure DevOps project for me. It's building out my repository, it's building out my builds and my releases all for me and it's actually going to do a deployment. Now this takes a few minutes to set up because there are several moving pieces and it is doing a deployment but I have one that's pre-baked right here. And so you can see when it's done building you have your CICD portion. This is the DevOps portion on your left side. You can see your Azure resources on the right side but what I find really cool is you can go into these and these are deep links into Azure DevOps. So if I click here, this will throw me right into Azure DevOps into this project and now I can see that it actually gave me an ARM template for what it deployed. I can see my application here. I can fork it, I can clone it, I can do all the things that you would normally do with a Git repository and that's awesome. And I can see, I can drill right into the build, I can drill right into the release and I can also hit the application. This is a live application. This URL will work for you as well. It's just a demo application so it's nothing robust but it is an application nonetheless. So something else that I want to mention that's really cool, you can build this scaffolding right using a DevOps project inside of the Azure portal. But once you have that built, this is an ASP.NET app, that's all it is. So I can go in here and take all this code out of my repository, push up my ASP.NET core app and have it deploy automatically to my testing environment. Now it gives me a quick and easy way to test this without having to set up all the bits and pieces myself. Not only that, if you don't want to mess with this repository, you can actually go to your builds here and this is just a normal, just like the other build that I showed you as a hosted task runner and my sources are right here. So I can change the source here that my build is actually pulling from if I want to. So you can set this up, you can change out your source or you can just change out the information in your repository and you are instantly or almost instantly working with a fully DevOps project. And so that's really powerful. I implore you to go check that out and try it out. But yeah, so my work here is done. Let's go back to this. And that's all I have for you. If you want to connect with me, I'm on Twitter, I'm a cloud advocate, like I mentioned, and I'm at ZDevTowah. And here's some good links if you want to take a screenshot of this or a picture of this, make sure to follow at azure DevOps for the latest information. And that's it. Thank you so much.