 All right. We are here with Jeffrey Palermo. Hey, Jeffrey, how are you? I'm great. How are you? I'm excellent. You are going to talk to us about azuredevops for.net. Absolutely. It's a really exciting topic, and let me share my screen. All right. It should be on now. Today, we're talking about azuredevops for.net and falling into the pit of success. I'm so glad that you're here. If you're tuning in to this session, then that means that you want to get more done. You want to move faster, you want to produce higher quality so that you can deliver for your team, your company, your customers. That's what this session is about, falling into the pit of success. There's so many choices. The complexity is endless, but I'm going to narrow it down to the seven key elements that you need to put into your azuredevops pipeline to move fast and build in a smarter manner and run your systems with confidence. I know from experience that if you map out your software delivery process and then automate it, you will deliver more, you'll absolutely love programming again. But we do have an enormous problem, serious problem we're going to have to deal with and solve. Most teams automate work for their own customers by producing software, but then saddle themselves with new administrative work to build, deploy, and monitor software that it relieves their customers of their administrative work. There's no reason that the cobbler's kids shouldn't have shoes. I work with teams all the time where one of the most senior, most capable developers is trapped by the task of deploying the software because he's the one who understands the software the best. So they take their best talent with the most experience in the software and reduce them to weeks full of administrative tasks. A deployment is a set of administrative tasks, copying files, changing a config file, configuring a credential, starting a service, and then doing it again, and again over and over. We all got into software because we saw the tremendous power available to us. We can write code and make the computer do something that makes ours and our lives better. So then why should we settle for a process that takes people with technical creativity, you, and turn them into an automaton? So for you managers listening in, I want to share with you what goes on in the brain of your people who have to do these manual processes over and over. We as humans are always on a pursuit of happiness. Whether we get fulfillment and serving others or making something new, your people aren't finding happiness in the process of manual builds, environment configuration and deployment. They want to get it done as fast as possible so that they can get back to why they get into software in the first place, to create things, to solve interesting problems, to make others' lives easier through software. As a result, the manual tasks are error prone and just mind-numbing. The more your staff endures tasks that don't bring happiness and satisfaction, the more they become open to perhaps considering other employers that might be able to provide more work that does bring satisfaction. So whether you're an individual developer, a lead of a team, or a manager in technology, this talk is for you. So today's session, we're going to talk about the pipeline structure. We've already discussed the challenge that we're faced with in software and how DevOps solves that. Next, we'll go through the key seven stages of the DevOps pipeline, and then I'll show you how to get started. So I want to give you something of value and help you get automated. I don't want you to continue to be frustrated and sometimes trapped by the software that you work on. And I understand lost weekends and surprise over time due to software builds and deployments. Over my career, I've helped tons and tons of people to do this. And I want to just give you a copy of my latest book for free, not selling anything. I want to give this to you for free. I want this to be in your hands. We gave the preview edition out of the build conference, .NET DevOps for Azure. And it exposes the secret about how any team can have a fully automated DevOps pipeline using Azure DevOps services by following a concrete seven stage design. And so here's what you need to do. You read the book and I'm giving you a free e-book copy just send me an email for being here today on the .NETConf or even stumbling on the recording. Then second, you need to understand the seven stages of your DevOps pipeline, which I'm giving you now in this talk. And then three, launch your .NET DevOps pipeline and use the free public project as a template. It's a free community project to help you get started with Azure DevOps services. And you'll find that in the book. And if you do this, you'll have a fully automated DevOps pipeline using Azure that will enable you to move fast and with higher quality. And also you can tune into the Azure DevOps podcast and get more information there. So let's dive right in. The seven key elements of a DevOps environment are the pre-code design process, how you set up your version control, which sets the stage for the rest of the automation, your build, and then your levels of validation which include full system testing, user experience testing, production release, and then telemetry observation. We have to make sure that we are watching how the system is running in production. And so to look at how that would lay out, in Azure boards, for example, we have the top level, that is your pre-code design process. There's four types of design decisions that have to be made before you put your hands on the keyboard is the conceptual definition. What the heck are we building? That's the good old fashioned requirements. User experience design, wireframes, what's it gonna look like? How's the user gonna use it? Then technical design, libraries, patterns, architectural changes, and then acceptance criteria and test design, that is what does it mean to be done and how are we gonna test this once it's put together? Armed with that, we're ready to code and then move on to the next pieces. This is what it would look like in Azure boards. You're gonna configure the columns for you. Nobody's full process has fewer than nine columns because ahead of development, ahead of the column that represents hands on keyboard coding, you need to represent these four different types of pre-code design because even if you don't have them on the board, these decisions are going to be made and if they're not made explicitly by the right person or people, then a developer's gonna have hands on the keyboard and just have to make assumptions and make it up as they go. And so these are the four types of pre-code design decisions you need to have these represented in your process or you're just kind of kicking the can down the road. You need to structure your version control system. You need to factor out your Git repositories properly and one of the big things, mistakes that people make is putting more than one application in a single Git repository or maybe taking a subversion or a TFS repository and just dumping it into a Git repository and it has a huge tree of software and then they try to figure out how to do a DevOps pipeline, it just doesn't work. I'm here to tell you the rules that are gonna cause you to fall into the pit of success and putting one application into a single Git repository is the beginning of the automation chain that causes you to fall into the pit of success because we're going to have one build that builds one Git repository, one application altogether and produces a set of release candidates that all have the same version number. So you can have a large software system but it's segmented into multiple applications anyway. You just need to make sure that each application has its own Git repository so that you have the source of what is versioning. Then we need to build and there are various stages you need your private build along with your continuous integration build. If you haven't read the Addison Wesley book on continuous integration back from 2006 you need to read that book and because your private build is going to be leveraged by your continuous integration build. And so building whether it's test-driven development or build process, any test uses the natural pattern of a range act assert or set up, get ready, do something and then check to see how things went. And so these are the basic build steps there. Some people put static code analysis in the assert column. It's not required but notice that I have two levels of automated tests, unit tests. These are in-unit or ex-unit tests that do not call out of process. As a result, they are super fast because they don't call out of process. Then there's component level integration tests. These are the integration tests that you can run in the build process. So if you're calling out through entity framework to SQL Server Database, you can test that. Boom, that's an integration test. And notice that migrate database is here. I don't wanna gloss that over. Your applications generally use the database. So for your build process, you need to stand up a shell of your database so that you can run tests against your code to make sure that your application talks to the database and uses it. A continuous integration build that doesn't create the database that the application owns and depends on is woefully incomplete. So pit a success, make sure that your data stores are in your build, okay? Static code analysis is a proven quality control method. And so whether it's Roslin or any other static analysis tools, every language has static analyzers. Make sure that that is in your build process. Don't leave that out, okay? And then we're gonna publish test results. We're gonna package it up into various NuGet packages and publish it to Azure artifacts. So let's dive into an example and this example we're using is ASP.NET Core web application and a SQL database. And with any application, it's important for all of the components to be built and deployed together. If they reside in the same Git repository, they have the same version number and they are built and deployed together. If you don't know why you would be an exception to this rule, then you're not an exception. This is the pit of success. We build the solution, we run automated tests and package up our deployable components. And here we are full platform as a service application, Azure App Services, Azure SQL. And so in this case, we end up with four NuGet packages that are published to artifacts. Because you see we have three components that are gonna be running processes in our environment. We have the web application, we have an offline job of some sort and we have a SQL Server database. And so we have the app service, the web app we'll push our job into an Azure function and we'll push our database into an Azure SQL. And also we have some acceptance tests, some full system acceptance tests. Now remember back in our pre-code design process we listed out our acceptance tests. These are simple bullet points. But then going into coding, we create a full system test suite. If it's a web application, we're gonna use a lot of Selenium to actually pull open a browser and click around and test our screens. And so we want to package up the test suite that is the version number of this application so that we tie that all together. And then we are going to push those into Azure artifacts. Don't use the old build artifacts store if you're building new pipelines. Azure artifacts is where all of your release candidate packages should go and use that. Okay, so build steps. I wanna show you what your continuous integration builds generally gonna look like. And this is coming from one of the preview editions. So we had to install on the hosted agents, the SDK for 3.0, but that's released now. This is using all platform as a service. There is no virtual machine in the mix. Now for speed, a lot of teams use a private agent so that they have a VM that they control for the builds. And I like that approach and that's a good approach. This approach uses 100% hosted. And so there is no server that you have to spin up. Therefore, when you grab this template and when you do it this way, you're gonna get up and running really, really quickly. And so first thing we're gonna do, we're gonna use Azure Resource Manager and tie it to our Azure subscription and actually create a SQL database just for the build process that we're gonna throw away after this build is finished. Then we're gonna run our build script which is a PowerShell build script. The private build that runs locally is just simple PowerShell. And just look in the book, I give you a template for that build script, it's not complicated. But after that build runs, which includes the msbuild.exe or the .NET build, those kinds of commands, it's doing all the compilation, it's running the in-unit test suites or ex-unit. And then we publish our test results and then we're gonna do a, and it also packages up and we're gonna do our NuGet push. And then we call into Azure and say, hey, throw away my build database so that we clean up. This is what our whole pipeline is going to look like in Azure DevOps services. So we're gonna have our continuous integration build tied to the Git repository that automatically kicks off. And then we automatically kick off the various stages. And the template will soon be converted to YAML that just came out at the build conference. Those things are being enhanced and that's getting better and better every day. So YAML will be the future, but most people who've adopted this already are using the steps. And so I'm showing you the steps which easily convert to YAML just for clarity. And so we have TDD, UAT and production. There are three types of environments, three unique types of environments in your DevOps pipeline and you need at least one of each. Remember, this is the pit of success. This is the rule of thumb, okay? Everybody knows production. You can have one, you need at least one. And sometimes we have a different production environment for each customer. So you can have multiple. Then we need a manual test environment. We call this UAT for user acceptance testing. You can have multiple of those. We find common manual test environments all over the place. Dev, test, QA, staging, those are all manual environments. You could have as many as you need. And then there's the TDD environment. It is the automation environment. There's no humans allowed on this environment. It is for full system test automation. It is for running test suites that require a fully deployed environment in order to run. And so functional Selenium tests that are the execution of your acceptance test? Perfect for running on there. So you see in our pipeline, we have 100% of our tests did pass after the TDD deployment. Let me show you what that looks like for when you configure it. These are the things you need to put in it. So the first thing that we do is we give the signal and send a message over to application insights that we are performing a release to this environment. That is super important because, and I'll talk about telemetry after a while. We tell application insights, hey, we're starting to deploy. Then one at a time, we grab a deployable component that is a NuGet package in Azure artifacts and we deploy it. So we grab our database and then we use Azure Resource Manager to create our database in the TDD environment. Again, we're using infrastructure as code here. The TDD environment does not exist. We're creating it on demand. We're using it and then we're throwing it away. So it's super cheap to do this. And for feature branches, you can have as many feature branches as you go and you can have a full deployment with a full system test run even before you do a pull request. Really powerful. And then we're going to, going down the list, create the database schema. Now our database is ready to go. Then we're gonna grab, I'm just truncating it here. We're gonna grab our web application package, create the Azure app service, do the deployment, start the website. Then we execute the self health check. That is important every time you do a deployment. It could be as simple as a PowerShell invoke web request and you call out to some endpoint so that the application can say, hey, I'm here, I'm started up. All of my dependencies are reachable. That proves your configuration. And I am ready to rock. Now here comes the full system testing. We download the package of our full system test. Then we push in the connection string to the database and the URL for whether web application is. And then we use the Visual Studio test step to run our full system tests, which is actually going to open up a browser on that VM that is the hosted agent and it's gonna run all of our acceptance tests. And then after this is all said and done, look, we have an Azure resource group deployment that actually deletes the resource group and throws away this environment because we don't need it anymore. All right, let's dive into what the full system testing looks like after it runs, because this is really sweet. This is really empowering. I think a lot of you understand unit tests and a lot of you are using integration tests, but we find that UI tests or full system tests that are driven through the UI are not as often used and they are absolutely empowering and the perfect implementation of the acceptance test criteria, which is a common part of Scrum because a lot of teams I know are using Scrum for project management. And so this is the view of the, this application has six of these full system tests that run and a powerful thing is that we can actually do a screen capture of every single screen as the test moved through the application. We can capture them and Azure DevOps services happily just grabs all those attachments and makes them available on absolutely every deployment, every stage, every test run. And so if we zoom in on what that screen looks like, we can see that what we're showing here is the inside of the browser and it doesn't grab the title bar or the Chrome of the browser, but it just grabs essentially the document element, the body of the screen that you're looking at. And so it's typing in those text boxes, it's clicking buttons and it's actually driving and recording what that screen looked like. Really powerful and really easy to do. And the free Azure DevOps Services project template that we have available online has literally this examples of this you can get up and running really quickly. So let's look at how the different environments are arranged. Here's a principle, never do anything in production for the first time. Everything that you do while deploying to production should have been done at least once and preferably multiple times in environments prior so that we can see all the things that we do in our in our TDD environment, which no humans can use that because if they try to get on it, it's just gonna be, the environment's gonna be ripped out from under you. So no humans allowed, it's just to deploy and run some test suites and then UAT or whatever you choose to call your manual environment, manual test environment that comes next. But we're going to load test data on demand in TDD. We're gonna recreate the environment, recreate the database, run acceptance tests. We're gonna deploy that completely unattended all the time. We're gonna destroy the environment. Now for our manual test, manual test environments, we don't do as much and you can see that on the chart. Now let's talk about telemetry. Every one of these runtime components needs to be monitored. Now Azure Monitor wraps up some services that really make this easy. And so every one of these can be attached to application insights. And if your application has things that run on VMs, log analytics is your answer to get absolutely everything that doesn't have native application insights integration. But let me give you the principles for falling into the pit of success with telemetry. Everybody knows logs, log for net, just flat file, log files, trace. But there's two others that you need to make sure your application is emitting. Metrics and events. You probably have applications that create a data warehouse or a star schema or some type of queryable denormalized data store that analytical reports can be run off of for your users. Well, emitting metrics and events gives you that same type of capability where events are akin to dimensions in a star schema and metrics are akin to facts in a star schema. And that way you can select by events, group by events, and then do average and sum and min max over your metrics. And you are creating a data warehouse of what your application is doing. And that's absolutely empowering. And then you need to take all of this information and make sure it's available in a centralized store. Now application insights gives that for us. And this is on the screen just a really quick snippet of some of the free things that application insights gives you just by grabbing the Nuke packages. Now if you go to the Azure portal, you can also see our deployment markers. When we said, hey, Azure application insights, I'm deploying that little arrow is the deployment marker. And if something goes haywire right after that, we can click on that. And in application insights in the Azure portal, we can see all the information about that deployment and link right back to it and where it came from. And so that's to tie it all together. Now, this is the seven key elements of a DevOps environment. Precode design process, version control structure, the build, full system testing, user experience testing, the production release, and then telemetry observation. You need all seven. Don't stay frustrated by a slow and manual process. Take pride in delivering to customers faster. Automate your DevOps pipeline so that you can ship software quickly and also preserve your weekends, okay? Now, remember, send me an email so I can send you a free copy of my book that walks you through in detail everything you need to set up. And of course it refers to documentation because the Azure DevOps services has great documentation. And I didn't wanna regurgitate documentation here on this 30 minute talk. I wanted to give you the guidance to fall into the pit of success. And if you haven't, if you're struggling to get started, yes, just do it that way. And as you read the book, use the included Azure DevOps Services project template that's linked here bit.ly on the top right, bit.ly slash.net DevOps project. And literally get up and running within a day. Feel free to copy, literally copy that completely working project along with the infrastructure as code and Azure ARM templates. Just attach it to your Azure subscription. You'll be up and running fast. And I do a lot of DevOps education webinars and the next one I'm doing is how to organize your Git repository to make DevOps automation easier. And also another resource is the Azure DevOps podcast. But if you email Jeffrey at clear-measure.com, I'll send you that free book and I'll also post the slides and tweet those out at Jeffrey Palermo. And I'll be happy to take any questions that there are. Thanks, Jeffrey. That was fantastic. We don't, I don't know that we really have many questions. So just take a couple of minutes and what's, what are your best, what are your recommendations for how people get started doing this? I think, you know, people have seen a lot of DevOps. They definitely want to do this. I'm going to dive in. You know, I've got an hour here, an hour there. How do I, how do I get started and get up to speed? Well, if Azure DevOps services is completely new, then you need to get the skeleton working first because you're going to have applications and everybody has tons of applications. And if you try to, try to start automating one of your applications first, you're just going to really struggle with the complexity of your application and the new tool. So I recommend going online, creating the new org and then just downloading or creating a skeleton, a shell of an application that doesn't actually do anything. That way you can get the automation down without being distracted by the features. And so, but there's a lot of concepts there. And so if the, the shell of the application that the community, the community template that I talk about, that's the jumpstart. And but either way, get a shell of an application, create the private build, the continuous integration build, throw in your unit test suite, integration test suite and a full system test suite that uses Selenium, make sure you can have one function and it calls a nothing query to a database. And then three deployments, a test automation environment, a manual test environment and then your production environment. And so if you can get just the skeleton of your pipeline with a, you know, file new project type shell of an application and Visual Studio solution, then you can get all the pieces accounted for. You can see how it all fits together, see how it flows. And then you can start adapting one of your applications to the pipeline and you'll sidestep a lot of confusion and a lot of complexity because you will have a working pipeline for an application that doesn't do anything but you'll have that full working pipeline and you can adapt it to, we've seen clients that have 100 plus applications with no automation and it's a mountain of effort but that's a way to get started. Perfect, cool, thanks so much. Well, thank you so much, Jeffrey. We're taking the time to share your talent with us. We're gonna get going here. We're gonna get Jay Power talking about static content. Thank you so much, Jeff. Awesome.