 Hey everybody, Martin Woodward here. Today, I'm going to talk to you about.NET DevOps, so how to do DevOps with.NET. My name is Martin Woodward at Martin Woodward on Twitter, if you want to send some questions through, and obviously use the hashtag.NETConf. I work on the Azure DevOps team, the newly announced Azure DevOps team, and I'm going to go through some stuff today. So let's get started. Right then. What do we think DevOps is? It's useful to level set on this. First of all, DevOps is not a product. DevOps isn't technology. DevOps is the whole process. It's about people, process, and products allowing you to give continuous delivery of value to your end users. The people and the process, like they're the hard bit, the people are always the hard bit, especially when they're trying to drive culture change in your organization. Bringing process in to support those people is also what you need to do, and then the tools to support the processes. Now we have tools, you can get tools open source, you get tools from other people. It's about the continual flow of value. We find that teams that are doing DevOps are actually delivering quicker, delivering faster. So if we look in the market, there's a state of DevOps report that's just out now. If we look at that, we actually see around about 46 times quicker deployment. If you look at the Stack Overflow Survey from 2017-2018, you actually see that developers who ship more are happier, and it makes sense really. If you're shipping frequently to your customers, you're getting live feedback from your customers, then you're going to be a lot happier with your results. You're going to know that what you're doing is the right thing to do. You need to get your teams, you need to try and remove all these obstacles and get them shipping quickly, and get them shipping to your customers, and making sure you can then learn from your customers as to what happens, and if it's good or not, have you made it better or worse? The key thing with DevOps is to be doing incremental changes the whole time, slowly and iteratively improving, or quickly and iteratively improving really. So when you're trying to learn and improve and deploy quicker and learn quickly from your customers, what sort of the key technologies you need to be on the lookout for to help you do that? It's no good just having your application, pressing F5 in Visual Studio, and then it'd be a real complex process to get what you've built out into the hands of your customers. The harder it is to do that, then the least often you do it, and the longer it takes, and that slows down the flow of value to your customers. So some key technologies to look out for are around continuous integration. Hopefully most people are doing this now, continuous integration with, say, Jenkins, or with Azure Pipelines, or with TeamCity. You know, any kind of CI build server will really help you do your builds automatically and make sure your builds are of high quality all the time. We then have continuous deployment. So that's being able to take what built, did it work, is it good, and actually take that package and ship it to your end users. Now that's easy when you're shipping to the cloud, when you're just deploying web apps and things like that. We'll talk a little bit today about how to do continuous deployment with desktop applications as well. And then finally, it's no good having all this stuff helping you ship faster if you're not learning at the same time. If you're constantly just shipping quicker, constantly just shipping fast to your customers, how do you know if it's better or worse or not if you're not looking and monitoring and seeing what they're doing and seeing if you're making it better or worse? You might just go off in the wrong direction a lot quicker. So it's very important that you build monitoring in and build learning into your DevOps Pipelines early on. So you can tell, have I made this better or worse? Are users using my software easier? Are they deploying quicker? Are they able to make the changes they need to do? Are they able to find the functionality? Are they running into any errors, those sorts of things? And being able to get confidence by what your users are doing in production that allows you to then move on to doing things like testing in production and being able to have real users use your system for real and actually get live data from real usage on your customers. Now on Tuesday, well Monday we announced on the blog post but then Tuesday in the studio here we had a live stream talking all about the new Azure DevOps services. So what we've done, if you're a VSTS customer if you're familiar with VSTS we've taken the core functionality within that and we've broken it into a set of services and they complement the existing services in Azure to help you do DevOps with your teams. So we've got Azure boards which helps you do planning, pipelines for build and release, repos for doing source control, test plans and artifacts. So we've taken one service and we've taken it up and we've broken it up into five services called Azure Pipelines, Azure Boards, Azure Repos and they complement the existing Azure services that are out there today. If we take a look at getting started with a continuous integration continuous deployment process there's actually a cool little feature built straight into the Azure portal called Azure DevOps Projects. You can very, very quickly and easily come in and set up a full end-to-end pipeline that uses the Azure DevOps services and plums them all together for you and gives you a skeleton and then you can take that and customize it. So let's have a quick play and show you how that works. It's really easy to get started. So I'm gonna come in here and just go to the Azure portal and here I am and you notice you've got DevOps projects. I've got it pinned to the top because I do this a lot but if you need to find it you can just go to all services and then find DevOps services, DevOps projects. I'm gonna click on my DevOps project here and we'll see all the ones that I've got and I've got a bunch of them. Sorry for some reason, there we go. Let's clear some subscriptions out here and then there we go. I'm gonna load this up and I'm gonna quickly create a new DevOps project and then within my DevOps project I'm gonna say what do I wanna do? I'm here at .NET Conf so you know, don't need to do any of this stuff any of this Python, go and all that. I'm gonna go with .NET, that's the way to go. It's the only true way. So we're gonna come in and then say what type of .NET application we want to do. I wanna try out, if I'm gonna do all this DevOps goodness I'm gonna go with a fancy, shiny, brand new ASP.NET core application. But you know, I want a real one. I don't just want a hello world so I actually want a SQL database back end that I'm gonna do some real work with. Get that all set up for me and do the hard work of plumbing the database, you know, doing all the deployment scripts that sort of thing, hit next. And then finally, how do you wanna deploy it? So do you wanna do a web app? Do you wanna do a VM? In the future, there'll be more options here around, you know, dockerizing, deploying it to AKS, that sort of thing. So I'm gonna just do it as a web app and then I'm gonna use an existing Azure DevOps subscription. So being on the team, I have a ridiculous number of these but I'm gonna use the happily named Martin Woodward one and then I'm gonna create .NET Conf 18 as my project. Yep, that name's available, fantastic. And then I'm gonna tell it where to deploy it to. Wow, .NET Conf 18, the website is still available. Awesome, this is really handy. So I'm gonna come up here and I'm gonna go deploy it to West Europe because that happens to be close to where I live normally and then just tell it to run and I'm gonna hit done. And that's gonna do all the hard work now of getting a basic project set up, setting up a simple CI CD pipeline for you, actually creating all the resources in Azure you need to be able to deploy it to. So an Azure web app site, you know, Azure SQL database and then get the application, build it, deploy it and have you a skeleton application to run to. So while that's running, it's gonna give me a little notification. People who are following the live stream, if they wanna try pinging .NET Conf 18.Azure websites.NET it'll be there eventually, it'll start to pop up. But while we're waiting for it to appear, you can see here it's the deployment starting for me. While this is all waiting, I'm gonna jump over and show you what an existing one looks like when it's created. So if I come in and I just look at this .NET Core one I did last night, we can see it's currently running, we can see my CI CD pipeline. So the code, we can see the build that last succeeded and the last deployment into the dev environment and then where to go look at that application. So if you wanted to go look at this live, you can just come in here and browse that application and you can see it will say hello world once it comes up and you just hammer that, there we go, the power of the cloud. And then if I come in here, we can actually go look at the code that's part of this. So let's just do that. Let's just go straight in and jump into the code. This is stored in my Azure DevOps account in my in Azure repos. So I'm gonna come in and I'm gonna do .NET Core project. And this is what the new look and feel, once I've logged in, this is what the new look and feel is like for Azure DevOps services now. So you see you've got, it all looks shiny, it's a lot faster, it looks very different to the old VSTS. And what's also quite interesting is these services here, you don't have to have all these on. So if you're using say Jira with GitHub, but you're using Azure Pipelines to do your deployment, you can just have Azure Pipelines enabled. You don't need to confuse people with all this functionality you don't use. So if I come in and do my project settings, maybe for this particular one, I'm not using my artifact service, I'm not using the test plan service, but I do want boards, repos and pipelines. So I can just switch those off there, go back to my project and it'll show you, it'll just see the things that I wanna see and not show you anything that's gonna confuse people. And one of the things we've done with Azure DevOps is actually taking the individual services that you might be using and make them a lot more pluggable, a lot more configurable. So if I show you the code that's currently here, we've got boards, which is the work tracking system, and I can quickly come in and just create a new work item. I'm gonna say create a bug. And if I look at this website, hello world is no good. I wanna come in and say, this is .NET Conf. We wanna be saying hello to the world, .NET Conf. So we'll come in here, yet create a new work item, say this is .NET Conf, that's bug 173. If we wanted to, we could come and plan that work out in our backlogs. We can use our agile dashboards to try and take that work and create new tasks and update homepage as a story. We can make that a story there and we'll say actually no, it's active. And I can use my finger, my screen and I can actually move these cards around live on the screen as well and do all that sort of thing. So there we go, move that around there to resolve but it's not yet, I'm gonna make it active. So we've got Kanban boards, work item tracking and look over here in source code. This is a source code that was created when I created an Azure DevOps project and we can see there's a straightforward application in here with a database project, a website, a web app and some unit tests and some functional tests. If I go into the main application and then let's just go look at, let's take the main view and we'll go to the homepage and index.html. If you're looking around, you notice I can actually now hide these, the nav bar if I've got limited screen space like I do when I'm presenting. You know, I'm showing you it in big screen so it's limited and I can come in and if I wanted to, I don't even need to clone this source code down and edit it inside of Visual Studio. I can actually come in here and live edit in master. I wouldn't particularly advise this. I can just come in here, live edit and say hello.netconf, exclamation mark, awesome. And I'm gonna commit that change directly into master. I'm gonna associate it with my work item I was just on, this is .netconf and I'm gonna commit that and it's gonna make that change. Now I've made that change in my application. If I go over and look into my builds, I can actually see already a CI build has been configured for me and it's already running and executing to run that build in the cloud. Microsoft have cloud hosted build service for you that you can use and you can have them work on Mac, Linux and Windows builds, all in the cloud. You get 1,800 minutes of build minutes for free for a team of five. If you're doing open source, you actually get unlimited build minutes to be able to do your application. So it's pretty awesome. There's a question here from Raymond Dillon is asking, hey Raymond, nice to see you. Can I integrate Azure DevOps with Microsoft Teams to get notifications of build? Yes, actually. If you go into the Teams marketplace, there is an extension for Azure DevOps to go integrate that into Teams and into your team channel. I'll see if I get a chance to show you that in a bit. I'm a bit worried what will pop up because I don't have a demo channel kicking around. So, but yeah, that definitely is there and we use that all the time. So thanks, thanks Raymond. Good to join us on live stream today. So we come in here and then, where was it? So we're watching the build that's happening and the build is just coming along here and you can actually see it running live. If I was looking at this from the Azure portal, so if I'm a, you know, not a dev, but I may be on, you know, the Ops side of the same team, I can come in and I can hit refresh. I'm going to just refresh the portal. It does update live as we come in, but let's just see if we can see it running. And we should be able to see here once it refreshes for us. Yep, it's currently running a build, the current builds in progress and then it's going to be deploying to dev in a minute. So, Yanni has asked the question, Azure DevOps sounds more like Azure DevOps only, no multi-cloud projects. So why are this naming? That's a great question and one I've seen on the, on best.netconf hashtag quite a lot lately. So feel free to mention that on me rather than for Beth because it's probably my fault that it's called this name, not Beth. So the, it's a suite of services like Azure Repos and Azure Pipelines are a suite of services to help you do it that are in Azure. Azure is completely multi-cloud today. If you want to use, you know, monitoring Azure application insights and use that to actually monitor an application that's in any cloud or on-prem, you know, so you can monitor your on-prem resources, you can monitor resources in AWS, GCP if you want to and you can monitor them already inside of Azure. The Azure DevOps services are exactly the same and it's a great question actually. One that is worth pointing out to people that it's not just for Azure, it's not just to deploy projects to Azure. So if I wanted to, if I go back to my project, it's currently building, I'm just gonna open up a new tab. If I was to create a new release, let's just do a new build just to show you some of the power here. If I come in and I'm gonna do new build pipeline and I'm gonna say where to wanna pull the code from, repos or GitHub or that sort of stuff, you know, you see it's instantly a lot more pluggable. So you can plug into whatever provider you want and right now we don't have it available for you but if you wanna talk to Subversion, you wanna talk to Bitbucket, you wanna talk to GitLab, you can just go and do that as it is. But what I wanted to show was, actually if I do it as a release, that'll be quicker, I'll leave this page here. And I'm gonna come in, I'm just gonna create a new release pipeline and I'm gonna just say, start with an empty job, yeah, empty job. Okay, cool. And then if I look at the tasks that are available to me, so I'm gonna say I wanna add a task, you can come in and if I type AWS for example, I can come here and deploy my .NET workloads to AWS. I can do the same with Google, with GCP. You can deploy anywhere. If I wanna deploy on-prem, if I just wanna run a shell script for example, you can also do that. So we'll talk more about that in a little bit. So Azure is multi-cloud, Azure is hybrid cloud, the whole of Azure is, so hence the name. I know a few people, especially Visual Studio users who were like, well, you know, I'm in AWS dev, like this seems weird to me. Azure is multi-cloud, all of it is. So, you know, it isn't weird. We have a lot of customers that also have, you know, a Java developers or Linux sys admin and a product called Visual Studio team services to those people wasn't particularly welcoming either. So it's a trade-off on both sides of the house, but it's a service that completely runs in Azure. It's a service that's integrated with all the Azure services for doing operations and management. So it makes sense. So hopefully that answers the question, but feel free to shout at me at Martin Woodward if you disagree strongly and we can have a discussion on Twitter after this. Okay, so away from the naming controversy. If I come in and I look, that actually that build is currently in progress. So I'm just gonna jump back in here again and actually see where we are. Yeah, so it's now finished. And then if I look at my release pipelines, I should hopefully see a new release has been configured while I was talking about, yeah, there we go, about naming. So there, the dev release is currently deploying and we see we've got other releases here that have come in and have been deployed previously. So we can go look at our previous versions, but we're currently looking at that release that's deploying into production. If I look at that release here and actually show, I'm currently running four out of eight tasks. I did that drop. So if I go back to that drop and actually see what was I building, this is the thing that I built. So all my unit tests passed. I had a whopping three unit tests. All of my code coverage was done or that sort of thing. And you notice there was only one change associated with this build. So you get an end to end traceability between what's deploying, what's deployed, and then what actually is in that new deployment. And then if we look, we can see that it was associated with bug 173. So not only are you seeing what's deployed where to which environment, what changes are in that environment, but also why, why was that change put into production? So I'm hoping now if I go back into my releases, just have a quick look here from the last currently still doing employment. So there we go. And if you want to go live to.netcore.azurewebsites.net, I'm hoping we're gonna get a new website coming up here soon. This is quite cool. And we can use that app insights. It's built in to our DevOps portal for us as well. So we can actually see how many people are live hitting this. So go on everybody on the live stream, hit .netcore2.azurewebsites.net. Give that a try for me. And then we'll actually look here and we'll watch the server requests, you know, peak up and down. And that's traffic that's coming now off the live stream, which is pretty awesome. Thanks for doing that. That's so cool. Right. So it's currently doing a release still. Let's come in here. I'm gonna hit refresh just to check. And I'm gonna come over here and see how this release is going, how long we got left to go. We're gonna, we maybe come back for this. It's currently been doing it for two minutes, which seems pretty slow, but we'll see what happens. Oh, hey, there we go. If I come back, let's just do a quick refresh, see what happens. So seven, eight tasks testing. Oh, it's doing the testing now. That's awesome. Well, you can see it's already updated. It's already deployed the website. Now it's running all the unit tests against it, which is pretty cool. So there we go. And if we have a look, how many people have seen that that's happening? Oh, quite a few. No failed request yet. Awesome, it's all working. Perfect. So that's that there. Watch this come through and wait for it to finish. Right. Well, that's finishing off. Shall we see if, let's see if that other DevOps project we created the, I'm gonna just come in and go up to my home page and I'm gonna say.netconf18. There we go. So there's the.netconf18 pipeline that I created earlier for me. And we actually see the same sort of files. We can see it's created the builds and the releases. Just to quickly show you what the build is that it creates. I'm not gonna dwell on this too much. But if I come in here and I edit the build definition, this is the default one. But you can learn a lot from this. It's just doing, you know, basic.net core stuff. So do a.net, you know, .net restore, .net build, .net test, .net publish, do some arm stuff, copy the database files over. So what it's actually doing is looking for any SQL scripts, copying them over and then putting them into a drop location. And then if I come in and come back in and look at the release, we can see that the release that it created for me, I'm just gonna edit that release pipeline and we'll see it's created it, you know, every time we do a new drop, so continuous integration, do a new build job. So it's gonna run all that stuff to actually deploy it out to Azure. But then if I wanted to come in and make it so as well as doing, maybe not just a CI trigger, maybe I wanted to add a new artifact. So rather than listening to builds happening, it was maybe listening to a Jenkins build happening. Or maybe it's listening to a GitHub action occurring, you know, you can configure all these things. Maybe when something arrives in your AK, in your Azure Container Registry or your Docker Hub, then actually go deploy it and push it out into production. So it's very flexible, very pluggable. But I might also can come in here and say on a schedule, do nightly deployments, do weekly, you know, daily deployments, whatever you wanna do. You've got all that configuration. We then have the dev environment. If I wanted to clone this environment and now create a production environment, I can just come in and do that. So prod or whatever or staging we can call it. And then I can customize my tasks to do what I wanna do. I can set properties, which is what you normally do, to actually define your properties between, you know, staging and production, what's different. And I can actually come in here and set a pre-deployment condition. So I won't deploy into production. And so maybe I've got an approver from maybe, you know, I've approved it. Or I'll do it, I can have it. So that's the approvers. I'll just switch it off and you can see it a bit better. I can have what's called a release skate. So I can have it delay the deployment by five minutes, you know, so don't deploy directly to production. Leave it in one environment first, let it settle, make sure it's okay and no fire alarms have gone off. No screamings happened on Twitter. And then deploy it to the next environment. But what I might wanna do actually is say, hook it up to work items. Don't allow me to deploy into production if somebody has created a defect, a bug or a work item recently. Don't allow me to deploy into production if Azure application insights is telling me production isn't healthy. Those things are built out of a box. You can just invoke any random Azure function. And one of my buddies actually wrote an Azure function which looks at Twitter sentiment analysis. And it can tell, you know, if your Twitter sentiment is good or bad and using Azure cognitive services and doesn't do a production deploy if the Twitter sentiment was bad, for example. So, you know, if we had the config change to do the rename and the Twitter sentiment was low and it wouldn't allow the production into, it wouldn't allow it into the next ring, which is quite cool. Right, so I'm just gonna leave that and I'll be saving it. Okay, so there we go. And yep, that's good. Right, that's enough of that sort of stuff. Let's jump back in. I just answered a couple of quick questions now while I can. If we, well, I'm switching back into slides. Excuse me. So, I can't pronounce the handle, sorry. It's L-I-C-J-A-P-O-D-A-C-A has asked how easy is it to migrate from TFS, so the on-premises version of Azure DevOps out into the cloud Azure DevOps services. We have a service to help you do that. It actually, you can do it with full fidelity migration go from your on-prem instance to the cloud. And that works. You need to be on a recent-ish version of TFS to be able to do that migration. You can't go straight from, say, TFS 2013 all the way into the latest Azure DevOps because what it's doing is it actually takes a copy of your TFS, your on-prem database, pushes it up into the cloud and then hooks it up into an Azure DevOps organization. So, it is good. You wanna practice, do a couple of test runs first and you also need to do your TFS upgrade first. And Venesh has asked, we set up manual test plans and cases. So, ah, great question, Venesh. He's talking about Azure DevOps and Azure DevOps services has the ability to do manual test planning. I showed you, there we go, you see test plans here and this is the ability to do test case planning and manual testing and test case runs but also sort of allow you to exploratory testing, those sorts of things, it's pretty cool. However, low testing doesn't come as part of the standard account. So, I'm just gonna quickly jump over here for you, azure.com, WAC DevOps. So, that's how you go and learn more about Azure DevOps. If I go into the pricing page, you can see for free you get the standard services, the pipelines board repos for up to five users and then you can pay per user. It's around about six books a user you pay. But then if I want, I can add additional parallel build jobs so I can have like, you know, 10 or five builds happening at the same time if I want to, I can pay for those. You can also pay an additional 52 books to get the test plan infrastructure. So, I think it was Venesh, if you want test plans, you actually have to pay additional for that and then it becomes available into your account. If you have a Visual Studio Enterprise subscription, then that comes with a free license for Azure test plans and Azure artifacts as well. Right, sorry, I'm gonna jump back into slides again and I'll answer some more questions in a sec. Right then, when you're trying to do DevOps in your teams, DevOps, remember, is about continuously improving, continuously getting better and removing those impediments, delivering the flow of value to your teams. What you want to do is figure out where your biggest pain is. The biggest pain right now in your process that nobody knows what we're supposed to be delivering, you know, I've no idea like what the current single, you know, the current sort of point of truth is in terms of what features the developer should be building. Is your problem around work prioritization? If it is, then planning and tracking is kind of where you want to be focusing, you know. If the problems are around your development processes, so maybe you don't have great code reviews and you're introducing a lot of errors into production or you're having a lot of problems with merge conflicts when you're trying to get into, you know, you have a team of say 10 and you're having sort of merge conflict hell, then there is where you might want to start and address problems with source control and, you know, use things like pool requests in Git or code reviews of NTFEC to kind of improve your process. Often today, you know, people are getting more sophisticated as time goes on when I first started doing this sort of thing. Source control was either source safe or just copying zip files around, you know. It's got a lot better. Most people are using source control now, thankfully. 90% of people are using Git as well. So build and test is an area where people have started to do investments and, you know, they're doing continuous integration. Continuous integration is not DevOps. DevOps is the whole process, bringing your team close together and focusing on the flow of value to your end customers. It's not just builds, okay? So people often forget that and just focus on CI CD. We call that Azure Pipelines. That's the feature that provides this part. So what's most common, and I see when I'm talking to most customers, is actually deployment, getting bits into production. Like that's a scary thing that requires, you know, somebody who knows how to like get onto the live boxes or knows how to get things done or maybe if you're doing a desktop application, you know, it's a massive process that requires years to get your users to upgrade. Like deployment is frequently where I see today most people having lots of lag time and issues. And so that's an area where we've invested heavily with the Azure Pipeline service to actually come in and be able to sort of help some of those things. Running your servers, you know, getting things, actually are your servers up and running? Do they go down all the time? Have you got the monitoring in place? Do you know what's good, what's bad? That is that the main problem that's happening for you right now? And then finally to say, do you know if your changes have made it better or worse? All too often I talk to teams and they talk about this amazing new feature they've deployed into production. But what they're not doing is, you know, how many people are using it? How many people are having success taking that feature you think's awesome and getting it and actually making use of it? People aren't using it. If people don't understand your UI, it's a bit like a joke. If you have to explain a joke, then it doesn't work. If you have to explain your system to people, it doesn't work, you know, it's not working. So let's actually look at usage and monitor usage to see is this application being successful for our customers? How quickly are they able to do their activity? What's their funnel? What's their drop-off rate? How often do they start doing something and fail, you know, and try and improve those all the time? And then loop and just constantly be unblocking little things and don't think, oh, no, I can't start doing DevOps because I need to do some massive deployment process and I need to go into Kubernetes and I need to do microservices and blah, blah, blah, all the buzzwords. No, just do a little bit of DevOps. Like automate your builds, automate a little bit of your deployment. Maybe it's just deployment into, you know, a dev environment that you can easily test that will hugely improve your productivity constantly just looking for little things you can do to make it better. Try it, get a bit better and then look again, what's the next pain point? Let's go and improve that. So if we look at the planning side with Azure Board, as I mentioned, that's got all the functionality for doing dashboards, for doing Kanban boards, that sort of thing, and getting reporting based on, you know, what work is available in my project and all those sorts of things. Talked about Azure Repos. That's the service that's the source control service. So a lot of people called TFS to a lot of people is just the centralized version control component of Team Foundation Server or what was Visual Studio Team Services. That's now Azure Repos. Azure Repos supports both Git and TFEC. So if you want distributed source control, use Git. If you're not sure what source control you want, use Git because that's what most people are using nowadays. If you're using a centralized version control system, if you find centralized version control is easy for you to understand and for your team to understand, then use TFEC, both work. It has an amazing, excuse me, has an amazing code search capability that understands the code. So if you do a search for say, through, you know, it'll find you the class that defines through rather than finding you the class that mentions through the most. It actually understands code and helps you do code searches really well. Then we have Azure Pipelines, which was played with quite a lot already today. This, as I mentioned, you know, sports.net, absolutely awesome. Not just C-Sharp and VB.net and things, but the F-Sharp team have a lot of, you know, plugins into Azure Pipelines to be able to do stuff. If you want to hook into fake and all those sorts of things, you can do that. They've got an amazing, really, really good, you know, integration in there. And that's what we're saying is a huge marketplace of plugins into Azure Pipelines that allow you to do things, so run node, run Python. And they're all open source. If you want to contribute as you can, you can do your own. So interestingly, the AWS publishing stuff, that's actually, we had originally started that and then handed it over to the Amazon team and now the .net team at Amazon are the people that maintain that integration. So they are the people that allow you to deploy from Azure Pipelines into AWS, which is pretty amazing. And I don't know, I love open source. It's great when we can do that sort of thing. It's completely extensible as I've shown you. And, you know, it works first class with containers, with Docker Hub, with Azure Container Service, with Azure Kubernetes Service, all that sort of good stuff if containers is your thing. Wantings I want to mention that we announced on Tuesday, when Monday or Tuesday, I forget, I don't know what time zone, you know what I mean, is the Azure Pipelines. That service we have available is now available for open source projects. You don't have to be logged into Azure Pipelines to be able to look at a build report. If you said it as public. And open source projects, and this is just crazy, I'm so proud we're able to do this. They get unlimited number of build minutes. You can just build as many, you know, as much as you want across 10, 10 parallel jobs. And you can pick if you want to run on Mac, Linux, or Windows, for all it's you could run on multiple platforms at the same time and do your pipelines. And it has deep integration with GitHub. Edward Thompson is speaking tomorrow, morning, Friday, and he's going to show, like the integrations with open source, he's the maintainer of the LibGit2 project and a few other projects on GitHub. And he actually show you how to get that hooked up and how to really delve into the integration with GitHub there. I'm just going to quickly show you some of these early adopters. The.NET Foundation, led by Oren Novotny, who's a legend in the community. He's been helping get projects on boarded into Azure Pipelines and been doing a lot of work to help there. And so some projects from the Foundation have come on boarder early. And then these people like the Amazing Cake team, if you don't know cake, it's a C sharp DSL for doing builds. So no more XML, no more YAML. You know, do your builds within C sharp. That's an awesome project. And that's again, got set up to use Azure Pipelines already. And we only announced this on Monday or Tuesday, depending on your time zone. So let's just have a quick play. I'm going to show you some of these projects and show you how they've got set up. So I'm going to jump in here. First of all, let's look at cake. So I'm logged in here. I'm looking at a pull request that Patrick sent off for, I don't know, but it's the latest pull request that's currently active. And we see all the usual stuff that happens on your pull request in GitHub, you know. We're coming in and we're having some discussion about it or that sort of thing. We've got approvers, projects run very well. It's got a very good sort of structure for deciding what goes live and things. And you see here, they've got all these checks that look if the pull request is going to work or not. And this is how you stop, you know, broken builds. Let's run a build validation on a pull request, so pre-merge. So the point of code review, let's run a build validation and see if it's going to pass or fail. And you see this one here has come in and it actually has passed, but it hasn't just passed on Windows, which is awesome. You know, but it's come in here and it's also passing on CentOS and Fedora and on the Mac and everything else. If I go look at the Mac build, we can go jump in and it takes us over into Azure Pipelines. And then we can see there's the build running on the Mac. If I quickly look over at logs, we get that. And if I look over at their releases, I can look at all their, sorry, builds, something I'm talking about. I can look at all their builds for their different operating systems. You've got the Mac one, the Ubuntu one, CentOS, Debian and see what's happening with those. So awesome. That's very, very cool. The next one I wanted to look at was one of the ones, was one of Oren's projects. So reactive extensions. That's an API, you know, for doing asynchronous stuff. So coming here again, hooked up with Azure Pipelines. I'm just gonna quickly click on the build badge and log in. The reason I'm logging in is because I'm vice president on the .NET Foundation. So I actually have access to this account and could do crazy stuff. But if you wanted to go to reactive extensions now and follow along with me, you'd be able to. So we come in here and we can see we've got code coverage. We can see like, you know, 70% of the codes, you've got 70% code coverage right now. We can tell that, you know, 99.94 unit tests have passed. So on every single build, on every single pull request, before Oren even bothers to review his source code, he can see that 7,500 unit tests have passed or failed. So he knows if it's worth his time to review the source or not of his pull request. Not only that, the person who submitted the pull request gets instant feedback if it's good or bad. And then the final one I wanna look at just quickly is it's not a .NET project, it's an electron project, but it's wanna know a lot of .NET developers use. That's Visual Studio Code. As you all know, Visual Studio Code is completely open source here on GitHub. And we can see right now, the build is partially successful. And you're, oh, what's happened here? So we can come in and we can have a look at that build badge and it's gonna take us over into Azure Pipelines. And we can see they've got a Visual Studio Code with being an electron app. They build for Windows, Linux and Mac. And we can see the Windows job and the Linux job have succeeded and all good. But it's failed on the Mac. This is quite common when you're building cross-platform applications. Cross-platform is hard, you know? It's just random stuff, like the differences between, you know, file systems, what's valid, what's not and all, you know, the differences in the way sockets work and things and even sometimes different chipsets can make cross-platform very hard. And the next big example we see that there was, the build was successful, but there were some issues. And if we had a look at what the issues were, we can see that the sources compiled, the unit tests all ran, but some smoke tests failed. And we can go in and we can view the detailed logs and actually dig in and see why those smoke tests failed on the Mac. So there's an instance of picking up a problem that it was only affecting the Mac and making sure it gets fixed, you know, as soon as possible. So Tony's asking around about testing and how does test assemblies work. So I'm just gonna quickly jump in here and show you some of the test tasks. So I'm gonna jump over and quickly look and release it, sorry, builds. It's all right. It's because I've not logged in for a little while, it's kicking me out again. So I'm gonna log in, look at this. Here we go, look at this, look at these builds. And I'm just gonna edit my build pipeline. And I'm gonna say, oh, the test assemblies, that was on the .NET framework one, sorry, wasn't it, it wasn't the .NET core one. Test assemblies is running and it's just running, you know, run the test execution, so that's basically doing a .NET test. But you wanna look at, Tony, you wanna look at, let's show you a different project that'll have proper a .NET framework project. Let's do desktop. Here's one I prepared earlier, but it's doing a .NET framework one. And I'm gonna come into here, look at builds. I'll bring it up. Basically, test assemblies, Tony, runs, it searches for things called, you set the name, the pattern, and it searches for things called start.test and it executes them. It uses a test runner to execute those and that test runner supports end unit, you know, X unit, all that sort of thing. Okay, and then there's another question from Vinesh around email notifications. We'll get to that one in a second. Philip has a question, is it safe to publish scripts containing confidential data over VSTs build agents? We're running in doc containers for security purposes. Wow, what a good question. Publish scripts. So what happens with your build agent, Philip, to try and help you explain this? We have a pool of build agents that are basically VMs running in the cloud. And even with Linux, where it's running in a doc and container, it's a docker container running in a VM. We, in our hosted build agents, we take them, we allocate it to a user, we run the build on that VM, and then we do all the tests, we get the results and then we destroy the VM and we release that machine back into the pool and then behind the scenes, we're spinning up the VM again and getting it ready to come back into the pool for the next user. So it's safe in terms of what was on that build machine is in an isolated virtual machine sandbox, and so which gets destroyed at the end of your build. I hope that answers the question. If you're really, really concerned about, you know, having data at all in the cloud, then let's show you what you can do there. You don't have to use our hosted build agents. You can use self-hosted build agents. So let's go cover that now, actually. What a great segue, Tony. Thank you very much. That's awesome. If we come in and we have a look, you can have in Azure DevOps hosted up in the cloud or you can host, you know, team foundation server on-prem. It's the same code base. You can have a hosted pool, which we've set up for you for free, Mac, Linux, and Windows, but maybe you want your own agent that you own. It's running in a VM, for example, but is yours in Azure or it's running in AWS or GCP. You know, who cares? Or it's running on-prem is the most common use case where somebody has got some, using Azure DevOps out in the cloud, they don't have to maintain it, they don't have to upgrade it. However, they're still doing their builds in their on-prem data center because maybe they're gonna deploy to on-prem and it doesn't make sense to do the build, push those binaries up into the cloud and then bring them all the way back down again to do the deployments. You can deploy a self-hosted build agent either in the cloud or on-prem and then it connects out over port 443, connects out to your Azure DevOps server instance and then pulls the build down from it. So as long as that build machine has outbound SSL access, then you can do that. What's worth noting is if you're using one of our hosted build agents, you can't connect a hosted build agent, you can't create a hole for it unless you make your boxes available on the internet, which probably isn't wise to be able to deploy stuff on the internet to your on-premise hardware. You can't go from the build agent or the hosted build-over deployment agent and actually deploy into your on-premises environment. You probably need to use a self-hosted agent to do that unless you were to open holes and firewalls, which I really don't recommend. What it's worth mentioning as well, you can deploy from Azure DevOps, you can deploy to cloud or on-prem and you can deploy to any cloud or any on-prem area and you can actually deploy to a combination of both. And this is quite common that customers keep, they've still got their on-prem hardware and they're keeping it now. They've not moved the production workload into Azure, but what they're doing is doing their dev and QA runs out in the cloud, out in Azure. And you can dynamically provision an environment using an ARM template or using Puppet and Chef or Terraform or something, some configuration as code to actually set up your environments and you can have those built out in the cloud, temporarily stand them up, run your dev and QA, leave it for a certain period for while approval and then when somebody marks it as approved within the Azure Pipelines, that then can move it out into production and then as part of that, tear down the QA environment because it's no longer needed. So then you can do all that sort of thing. That's actually a fairly common scenario for people to do. Okay, one of the things I wanted to talk about around that value chain, we talk about deployment being a common area where people get stuck and get slowed down. When I had a real job before I came to work at Microsoft, that was a very common area that was slowing us down, you know, doing stuff with customers because they would have their source code and they would complain about a feature not working or stuff and we're like, we fixed this and it turns out they're not using the latest version or to get a new version deployed out to everybody in the business who was using it, you just take ages, we used to have to wait for machines to get shut down and all sorts of things. So what you wanna look into if that's a problem you've got is one of these evergreen installation technologies. So the evergreen installation is basically always use the latest version. If you use Google Chrome or whatever or if you're using an app, one of the store applications or an app on your phone, it's always up to date. When you go into it, you've always got the latest version and to achieve that with desktop applications there's a number of technologies available to you. The one, probably the oldest one on the list is ClickOnce which has enabled you to do web deployments but as well as doing, you know, being able to easily install over the net, it also has an update capability in it as well to enable you to get latest versions. Squirrel is an open source application that allows you to do this and Squirrel's really, really straightforward to use and the thing that's awesome about Squirrel is it's actually packages using new get packages is what this, you know, that's how it distributes the updates between versions. With a Squirrel application it can check for new versions on app startup or on a certain schedule. It can download them and then you can define if you want to notify the user that a new version is available and they should restart or what's most common in, you know, most normal company scenarios, people log off and log back on during the day. So just have it to fire up the new version on new app start. So during the day it's downloaded, got the new version ready to go. Next day when people come in, they log in, start up the application and boom they're on that new version and that can shorten the amount of time it takes to get things into production enormously. The other great thing about Squirrel is that you can get it to subscribe to different channels. So using a simple registry key or even a UI setting, you can get it to have, you can have a dev channel like a CICD channel, what's currently on my build server so you can dog food it. You can then have a slow ring and a fast ring and that allows you to very easily define when people get updates and that allows you to do some testing into production. You can have a certain set of expert users that are opted into the fast ring and they can come in and actually get the latest bit sooner rather than your whole estate. So Squirrel's an awesome technology. And then finally, Squirrel also works with different versions of Windows, Windows 10 but also earlier versions of Windows. If you're lucky enough to have everybody in your estate running Windows 10, then you can use the Microsoft Store for business and education, which is your own private store where you can deploy your applications to and Azure Pipelines can deploy to all of these really easily. Azure Pipelines actually has an artifact service, sorry, Azure artifacts exists that hooks into Azure Pipelines and that allows you to store privately your Maven feeds, your NuGet feeds and MPMs and things like that. And that's a great compliment to something like Squirrel because with that you can promote easily NuGet packages from say dev to production within a channel, which is awesome. And then finally, we talked about test plans and that's the manual testing that we kind of already covered in one of the questions earlier on. Right, so you've got all these things, they're the main Azure DevOps services and then you've also got, how do you know if my application's better or worse? And this is where we have Azure Monitoring, Azure Application Insights and Azure Security Center to actually look for live things in your application and allow you to go do, it says root cause analysis, there is no root cause typically with a complex system, it's do post mortems, actually figure out what's wrong with your application. And then another cool thing that I wanted to make sure you knew about was Azure Lab Services. So if you wanna come in and create a dev environment, it makes it super easy to do that, spin those up and actually have configurations so that people don't leave these resources on. That saved my bacon one day when I was gonna do a demo for a friend and I went home to pick up the big bag of dongles you need as you do to do any demos nowadays, you need bag of dongles to project, went home, grabbed the bag of dongles, arrived at my mates to go do a demo to his work and then when I got to the car park, picked up a bag of dongles and realized I've left my laptop at home. I was like, oh, that's not what she used to me. So while I was walking from the car park to his office, I actually went in and went into Azure portal, told it to create me a new Visual Studio 2017 instance in the cloud for me, walked into these office and said, hey, can I just jump on a machine that's on your network, please? And then RDPed from his machine over into Azure and had a full dev workstation. Because all my source code was in Azure repos, I was able to just do a quick git clone because I was using OneDrive for my deck. I was able to go there and just able to do a demo really quickly. So that's almost serverless, serverless dev, I guess. There we go. We've just done some Azure function stuff. Ryan, it's time to start wrapping up and do some Q&A if we've got any questions. So feel free to send some along in the live stream. Just quickly, we've got Azure DevOps services, so Azure boards, Azure repos, Azure pipelines, Azure test plans, Azure artifacts. That allows you to go plan smarter and plan faster for your teams. We also have this amazing offer if you're doing an open source project, if you're a maintainer of an open source project, take a look at Azure pipelines completely for free. You've got unlimited build minutes and as I say, 10 concurrent jobs across Mac, Windows and Linux, which is just fabulous. It's just fantastic. And then if you want to get started and have a play, just go and create an account. So go to azure.com, whack DevOps, hit the get started for free button and then you can just have a play and just use it. Remember, don't think DevOps is this massive thing where you need to be amazing, have this fantastic pipeline, have a great containers and microservices, things. Just get started, just improve a little bit and every day, every sprint even, just try and improve your processes a little bit more and you'll get better as a team. Right then, let's go into Q&A. So thanks for your time, everybody. If you start dumbing questions, as I say, feel free to shout at me on Twitter, especially if you hate the rename, that'll be awesome. So we come in here and we do, yeah, let's go through some questions. So, Vinesh, email notifications. Is it possible to include build summary, so work items and things in the mail? Currently, it just says success, fail. You know what, Vinesh? I don't think it is, actually. There are ways of customizing those notifications. I wouldn't recommend any of them. What you could do quite easily, though, is use a service. We have webhooks available, notifications. So you could use a service there to actually come in and execute your own custom code whenever a build succeeded or failed. If you look at a service called Zappia, Z-A-P-I-E-R.com, they have a bunch of things where you can take outputs from Azure Pipelines and actually turn that into an email template and send it out. Next question from Ben. How does Squirrel and Azure Artifacts interact in terms of licensing? That's a great question, Ben. Right now, it's a user license for Artifacts. And so, yeah, we should see what we can do with licensing there in the future. If you've all got MSDN subscriptions, that's cool. But right now, a lot of people don't, so I'm hoping we can see what we can do around licensing and make that more affordable for people. Okay, any other questions? Or I think we're gonna wrap up, and it looks like Dan's gonna be coming up in a bit after the adverts. So I think I'm gonna wrap up. Thanks, everybody, for your time. Thanks for the comments on Twitter and things. I'm gonna go back now and I'm gonna answer any questions over Twitter. It's been awesome to be here. Thank you very much for having a conference. And yeah, just do a little bit of DevOps. That'll be awesome. Thank you very much. Take care, bye.