Deploying your application faster and safer

Just another WordPress site

Deploying your application faster and safer

[MUSIC] >> Good morning everybody How are you-all? Good Learning heaps of stuff so far? Excellent Thank you for coming along My name is Damian Brady, I’m a Cloud Advocate for Microsoft, which means that I come to events like this, so I get to talk about some really exciting stuff like DevOps, which is kind of my area Today, I’m going to be talking about deploying your application faster and safer So before we start, I thought rather than just go into all the details about what’s involved and why DevOps is important and stuff, I thought I’d start instead with a little video which demonstrates a bit of the idea of what DevOps is for So why DevOps is important and what things can look like before and after DevOps This is an analogy, so bear with me But I think this is a really good demonstration So let’s just have a watch >> But Holland comes in for a pit stop, time to refuel and change tires Lou Moore himself changes the tire Only four crew members including the driver are allowed to work on the car It’s a tensed time, Holland stays in his seat anxious to get away, let’s watch >> The thing I love about this video is it’s uncomfortably long >> The tires are changed at last A crew man polishes the wind shield as Holland moved away just 67 seconds after he stopped >> So just 67 seconds So this is the before DevOps So now we’re about to see the after DevOps Right. So there’s a small difference The good thing about this is whenever I show that video people will come to me and say, “Look, Damian, that’s not really a fair comparison.” So, back in 1950 there were only allowed to have four people involved in this pit-stop So only four people were allowed to be involved in getting the car back on the track which is what the entire team wants What else was there? There is taking the tires off They have this new technology where they can just like a single knot and then pull it out, re-change the tire, put a new one on and it’s done in a couple of seconds They didn’t have to refuel in 2013 either In fact, I think recent rules they’re not even allowed to refuel. If that’s correct, yeah So all of these things are very different between the way they used to do it and the way they do it now So, not a fair comparison I say, “Yes, that’s exactly right. It’s not.” But that’s the point, right? You got this entire team of people who really just want to get this car back on the track, but you’re only allowed to use four of them Like if you have a skill set that can be used to get this value back in the team, like the car back out on the track, why not use it? So that I think is a pretty good analogy for DevOps What else was there, there’s the refueling This is a bit analogous to changing the architecture of your applications so that you don’t need to do as much work You don’t need to refuel You can just swap out bits of the application that you need to change, like you don’t have all of this downtime You can deploy a new car and then swap them out potentially I think that’s coming in future rules So there’s that Then the last one like the tires, taking the tires off right, there was somebody who is physically hitting that tire with a hammer to get it on, which I think is perfect So I did this kind of stuff for ages for about 15,18 years Can anybody tell me that they haven’t deployed something to production and then hit it with a hammer to get it to work? That’s a perfect analogy in my mind So things are very different than the way they used to be, but that’s kind of the point So this is the idea of what DevOps is supposed to be able to do for you, and how it can improve the situation to get that value back on the track as soon as you can So I’ve talked about DevOps a couple of times I mentioned that word but I haven’t really defined what DevOps Means The good thing about DevOps and also the bad thing about DevOps is it really depends on your perspective where you come from I come from a software development background So when I think about DevOps, I’m really centered around getting software out the door and into production,

so that deployment cycle But somebody who has an operations background, thinks about DevOps as maintaining availability and standard operating environments and being able to swap add environments really quickly and safely and things like that Nobody is wrong necessarily, we all just have different perspectives on what DevOps actually means At Microsoft though, we define it fairly broadly So the definition that we use at Microsoft is that DevOps is the union of people, process, and products to enable continuous delivery of value to our end users Now notice I said continuous delivery of value, not continuous delivery of features or continuous delivery of work items that are on the backlog, continuous delivery of value The only way to know whether you’re delivering value is to actually measure it when it’s in production If you work on a feature and push that out the door and it takes you six months and it’s in production but nobody uses it, you haven’t delivered any value, you’ve delivered a feature So measuring what actually happens in production whether what you’re providing is valuable is really important There’s a very big difference between saying to somebody, remember that feature you worked on for the last 12 months? It turns out the customers don’t use it, we’re going to scrap it, and saying, remember that feature that you started working on a week ago, turns out people aren’t going to use it the way we expect, so don’t worry about it, we’ll move onto the next thing One of them is a huge waste of time and the other one is a little bit more agile and this is what DevOps allows us to do, move a bit faster but safer to measure that value that’s in production So the other question that we get as well is, why is it important to do DevOps? What’s wrong with actually deploying every three months and just making sure you survey your customers ahead of time to make sure you’re working on the right things and so on The short answer to this is, it’s important because your customers are already doing, sorry, your competitors are already doing it So if it takes you three months to fix a bug or to make a change to a feature that makes it more usable for somebody, and it takes your competitors an hour to deploy that fix Where do you think your customers are going to go? Now, you’re going to start losing customers You’re going to be out innovated by your competitors Even if your customers are not the end users or the end customers of your company, if your customers are an internal team in your organization, that department is going to start having trouble keeping up and keeping their customers because the software that you provide and the infrastructure that you provide is not able to be agile enough So even if your internal and not dealing with customers directly, this still applies So DevOps allows you to be a bit more agile, increase the velocity, so actually, you get your stuff out the door much quicker It does that by allowing you to reduce downtime and reduce human error Never send a human to do a computer’s job We make mistakes a lot So reducing that downtime and fixing things much faster, allowing you to reduce human error is really important and that enables you to stay up with the competitors and hopefully ahead of your competitors as well So the other part of this as well is that quite often when I say these things people will say, “Well, that’s just your opinion, is there anything actually behind this?” The answer is yes There’s a really good report that I always refer to call the DevOps research and assessment That’s the organization that publishes this report The report is the state of DevOps report, and it’s a very digestible 70 yard pages report that comes out every year The way they put that together is they, survey tens of thousands of software delivery teams and they do some cluster analysis and they group them into high-performing DevOps teams and low-performing DevOps teams and medium performing DevOps teams There’s a little bit more new ones in the report, but in general they compare the high-performing teams to the low performing teams What they find is that high-performing teams deploy on average 46 times more frequently So they’re deployed more often The lead time for changes is lower, so that’s the time from when they actually make the change in the code and have that running in production It’s 2,500 times faster than a low-performing DevOps team But then, and in some organizations this is counter intuitive, the changes that they do make fail less frequently So there’s a seven times lower change fail rate So the stuff they’re putting into production doesn’t break as much When it does break, they can fix it 2,500 times faster, because they’ve got this process that enables them to fix these changes push out to production and repair things Now, this is a real good academic research There’s real stuff behind this This report is a fantastic thing to show your manager if they say, “Yeah, we’ve given DevOps to you as a title change but please don’t do anything different We still deploy every six months.” This is a great way of convincing them

that things actually need to change So I’d highly recommend looking at that report The other part of that definition I showed you as well was about people, process, and products These three parts to successful DevOps So people is where I want to start So traditionally, in software development and software delivery, the developers would write some code, they may be package it up, they’d throw it over a wall to the Operations team and say, “Here you go, deploy this Here’s a Word document that we last updated in 2004 It’s probably mainly right, deploy the application and then maintain it.” This leads to a lot of problems Developers start blaming operations because they didn’t install things properly I mean it’s a .NET application, of course you need the .NET framework or I didn’t need to put that in the document Operations teams blame the developers because every time something changes, it breaks production So you get these two teams in the same organization who was supposed to be working towards the same goal, working software and production, but they are working at cross purposes So what I mean by that is developers are incentivized on change Everything a developer does is change You’re adding a feature, you’re fixing a bug, you’re re-architecting some stuff, you’re changing things So that’s their incentive Operations are incentivized on the exact opposite; on stability, and what hates stability more than change. All right So keeping things available, the easiest way to do that is to not change anything All right? So, you have these two teams who are working directly opposite purposes So that’s your first challenge, is to get these two groups, these two disciplines to work together for the same goals, deploying faster and safer So that’s the big thing To do that, you need a decent process You need to be able to handle your development, so you’re planning your development and testing your release after production, and then don’t stop there, you need to measure what’s happening in production and use that feedback to come back to the planning in the future as well DevOps is about doing this fast and safe, having a process in place that enables you to do this without thinking about it To do that, you need some good tooling around it Now, the good thing about Microsoft is it doesn’t matter which area of DevOps you’re talking about So planning and tracking of your work, the development and testing the release, and then your monitoring and learning There’s all these different things that you have to do at the stages But the good thing about the current Microsoft is we don’t force you to use our tools for everything So if you have investments in any of these tools or any other tools that help you with your DevOps process now, we are working hard to make it AZT continue to use those tools Azure DevOps is the product that can fit in and add those functions at the gaps that you have So Azure DevOps itself can do everything for all of these stages Like we work really hard between Azure and Azure DevOps to make sure we cover all of this, but if you use these tools already, then you can continue to use those tools But as I said, Azure DevOps is designed to do all this as well, and it’s designed for any language in any platform too So we’re not talking about just Windows and just .NET, we’re talking about any language running on any platform You can run Python on a Raspberry Pi using Azure DevOps, and I’ve done that before It’s fun. Somebody asked me whether you could do COBOL I don’t know, probably But basically, anything that you want to do in any language targeting any platform whether it’s Azure, on-premises behind a firewall on somebody else’s Cloud, Azure DevOps will support you there So Azure DevOps itself is a collection of five services, five tools, Azure Boards to manage your work item, tracking in the work that you’re actually doing, issues and bugs and things like that Azure Pipelines is all about continuous integration, continuous deployment or continuous delivery Azure Repos is where you can store your code if you want, but we also have incredibly good first-party support for GitHub, and then really good support for any other code repo that you have your code in as well Azure Test Plans for managing your testing efforts and Azure Artifacts for storing your packages and things like that if you have them internally as well What we’re going to focus on today because we’re talking about delivering faster and safer is really going to be around Azure Pipelines In fact, I’m not even going to have my code in Azure Repos, it’s open-source There’ll be a link at the end so you can download it if you want to anyway So we’re going to put it in GitHub, and that’s why they’re called loops in GitHub So we’re going to focus on Azure Pipelines Now, it goes without saying as well this is part of Azure So Azure DevOps itself and Azure Pipelines and all of the other ones work really really well with Azure, that integration is really tied So I think that’s probably enough talking about stuff The rest of the session is really going to be demo,

is actually walking through this, and we’ll start pretty much from scratch We have the repo in GitHub, but we’re going to build a full continuous integration, build definition and then continuous delivery and continuous deployment to a few different environments, and make sure we’re deploying not only faster, but deploying safer as well So we’ll start talking about that too So let’s get started This is a long room as well So if anybody at the back can’t read anything at any point, can you please just raise your hand, I’ll keep an eye out and I’ll zoom in if I need to So is this okay for everybody at the moment? Good. I can see a hand I probably didn’t do that very well Put your hand up if you can’t read that Okay. I’ll zoom in a bit This is actually not very important this bit But this is the GitHub repo where the code lives It’s a Node application, a Node front end that we’re looking at If you’ve been to any of the previous sessions in aligning pause, you might have heard of Tailwind traders So this is the Tailwind traders front end application At the moment, it just looks like this That did twice. Doesn’t look like that Although that would be a good starting point as for us So this is the Tailwind Traders application and it’s just the different products that they’re selling and so on Not terribly important, but this is what we’re looking at at the moment So we have our coding GitHub The first thing I want to do, is I want to build environment I want to define a way of building this application, so I can determine the code changes that I make, MIT makes, can still compile, can still end up with a real product So the really good thing about GitHub is that we have a GitHub application now So if you go to the Marketplace from your GitHub repo, I’m just going to search for pipelines, and scroll down a bit So Azure pipelines which now has 12.5 thousand installs, is the application that you can add to your GitHub account to give Azure DevOps and Azure Pipelines access to your code base So I’ve already set this up, but it gives you a bit more information about what you can do Hosted Linux Mac and Windows agents as well But here’s a really cool part The pricing is $0, which is reasonably cheap, and that’s free for public and private repositories So with public repositories, with open source applications, you get unlimited build minutes on our hosted agents, and you get 10 free parallel jobs at a time So you can run 10 builds at the same time for free with no limit to the number of minutes that you use on any of those platforms Mac, Windows or Linux If you have a private project, it’s 1,800 minutes per month and one job in parallel So it’s still free to a point, and then you can pay more for more parallel jobs and things like that So I’ve already set this up So I just need to configure Azure Pipelines, this application, and then just give it access to the repo that I’ve created or the repo that has the code in it So again, there’s a bit more information about what it can do I’ll leave you to read that later It tells you what permissions it needs and then you can either give it access to all of your repositories or just select repositories as well So I’ve got a few, but I also want to just add this Ignite to a repository that I’ve got as well So add that, I’ll save it, and this will take me into a flow which enables me to actually build my pipeline really easily as well So just to let you know, it’s asking me to login Hopefully, I won’t need to give any passwords or anything, and then it will ask me, what Azure DevOps organization, I am going to use? Or do I want to create a new one? So I work for Microsoft, I have a couple of these, so I’m just going to choose an existing one But you could create a new one straight away, and then I’m actually going to use an existing project, but again, you could create a new project So the organization is like your account, and the project is the project that you’re working on at the moment So, I’m going to use AbelTailWind So, Abel actually originally wrote this demo, so I’m just going to write all over the top of his stuff I’m sure he won’t mind So let’s continue that It’ll take us to Azure DevOps, and the next thing I want us to do, now we’ve connected GitHub and we’ve connected Azure DevOps or Azure Pipelines, is we want to choose the repository that we’re going to deploy So, this is the one that I just added, I’m going to zoom in a bit This is the one I just added, Ignite Tour LP1S2 So let’s choose that It’s giving me a warning about the code being public but the pipeline being private, so I will just ignore that for the moment What it’s done is it’s looked in my code and decided it thinks I’ve got a node application, so that’s the recommended pipeline template that it wants me to use But it also knows that a node one could be with React, Vue, Webpack, an empty one, or minimal pipeline, or an existing YAML file

So an existing definition or any of these So there’s all of these templates that know how to build various different things So right out of the box, you can choose one of these templates, but this is a node application I’m just going to use their standard one What it’s given me now is a definition of how to build a node application Now this is really basic It’s basically just using an Ubuntu-16.04 agent, so a Linux agent It’s doing a install node JS spec So it saying, you’re going to use 10 point whatever, and then it’s just doing npm install, and npm run build, and that’s all it’s doing So this is really just going to compile my application If you want to know what other tasks, what other pieces of YAML you can use, there’s a link to Docs which tells you everything that you can put in here Or that link here, which gives you a link to the docs but specifically for JavaScript, so that narrows it down a little bit more as well There’s also and this is relatively new There’s also IntelliSense in the browser, and auto complete and things like that So that’s really handy as well That gives you a bit more help hopes Saving is not the right thing So, I’ve got this basic built, I’m going to save that and run it, and what it’s really doing, is it’s creating an AzurePipelines.yaml file, the definition, and it’s adding that file to my repository and it’s committing it to the repository itself So, when somebody gets my code, when somebody pulls down the new version of my code, they not only get the code, but they get the definition of how to build that code too So, that if they need to make a change they need to build a new projects, they need to add some scripts or something to that build definition that lives alongside the code, and there’s huge advantages to this One is if you have a feature branch for example, that is going to change the definition of your build You can change the definition in that branch So you’re not affecting the master branch that everybody else is working on The definition of how to build this change is alongside that change, which is really handy as well The other thing that it does, is it actually sets up these build as not just a continuous integration build, but it sets it up in GitHub as a GitHub check or a PR check So if we go to GitHub and I think I can do that. There we go If we got to GitHub, and I’m just going to look at some previous Pull requests just to show you what I’m talking about Here’s a PR test So this is a previous Pull requests that we’ve since merged and closed, but you can see the Checks tab right here If I choose that, you can see at that point, it actually ran an Azure Pipelines built So when somebody submitted a Pull request, and this is really handy for public projects When somebody submitted a Pull request, it ran a build to make sure that the code they changed, we’re still going to compile according to our build definition You can use a different build definition for this as well, so it doesn’t have to be your full definition of how everything works It can just be maybe a compile and that’s it That’s all you want to do Or maybe just some linting, to make sure that they’re following your standards in your application So, that can be a checked to make sure that what somebody has submitted is not going to change All right. So this is doing a checkout This has actually started taking a little bit longer than it had been So we’re at 66 percent, we have been for a while which is fun, and no, I haven’t checked in the node packages So we’ll let that run. So this is just going to do a strike built, right? It’s going to compile my application, but it’s not going to give me any artifacts to deploy It’s not going to run any test, it’s not going to set any configurations So, I want to add that functionality, I want to add some more stuff to it There’s the YAML definition that you can use So this text-based definition But if you’re familiar with Azure DevOps or Visual Studio Team Services, which is the old name for it You’d probably be familiar with the Visual Editor, and you can still use that So when you create a new build pipeline, you can choose once you choose the location Oops, before you choose the location, you can actually use the classic editor which is the Visual Editor, and that will give you a UI based way of building your build definition So let’s just jump to one that I’ve created earlier, and so this is exactly the same thing It’s just a visual way of defining it So I can add and remove tasks Out of the box, there are thousands of tasks that you can use Actually probably not thousands, many, many hundreds of tasks that you can use, and if what you want to do is not out of the box there’s also the marketplace Our partners have created, well over 500 tasks, build and released task that you can use If what you want to do is not in either of those, you can either write your own script So you can write a Bash script for example,

or a PowerShell script, or a Azure CLI script or something like that Or you can write your own custom task, and either add it to the marketplace if you want or just add it to your own project in your own organization So you can really get it to do anything that you want Remember, we can run on Windows Linux or Mac OS as well So, this, at the moment is set to use the Hosted Ubuntu 1604 agent, but I also have access to a Hosted macOS agent Let’s just do that drop down again Hosted macOS agent, Ubuntu 1604, VS2017, VS2019, a Windows Container, or I can use my own agent pools if I want to install an agent on my own system, on my own infrastructure, which maybe has some third party tooling installed or access to different parts of the network, that the hosted agents are not going to have access to So I have that option for me as well So, you can really do whatever you want Then when you’re done, you can actually come to the agent job itself, and click “View YAML” and it will give you the YAML equivalent of this visual UI So you can copy and paste that into your definition and actually have that live alongside the code as well So, let’s actually do that I’m just going to copy that to the clipboard, and we’ll jump across I’m just going to do a Git pull, and you’ll see that now we’ll have an Azure Pipelines YAML file Let’s zoom in a little bit more So this is the one that it added out of the box, the default one But I want the one that I just created I just copied from the clipboard, right? So we’re using that same agent, we’re doing an npm install, we’re doing a bunch of Bash scripts, we’re packaging up the file itself, we’re zipping it up, and then we’re copying it up backup to Azure DevOps so we can deploy it later on So I’m going to save that, and this is just a file in my repository So I’ve updated that file So it’s commit that and Push it to Git We should see hopefully in our Builds Yeah, I didn’t need to change anything That it’s still running that first one Let’s see how far along it is Still checking out. It’s still at 66 percent That’s not a great sign Oh no, we’re good All right. But in the meantime, I’m going to cancel that one We should see in our builds It’s going to pick up the new build definition that new one that I just created that change We can follow that one through If we want it’s going to do the same thing, and it’s probably going to take a little bit longer than I wanted to as well So, we’re going to move on Before I do though, does anybody have any questions about what I’ve shown you so far? We’ve really got this build definition that knows how to build our application, and that definition lives alongside our code in that Codebase. Yes >> [inaudible] >> So, the question was, is it possible to run that build definition on your working laptops or on your development laptop? The short answer is no Part of the reason is that you can in your build definition have multiple jobs that run on different operating systems that require different things It’s not quite as simple as running all of these tasks one-by-one It’s running all of those tasks on different environments in different locations So you might have tasks that run on a Windows machine, tasks that run on Mac OS and so on So that thing wouldn’t be running locally on your local machine If you wanted to actually run those builds on your local machine, you could set up an agent, and have that in your private agent pool, and then it will physically run on your machine but it will still act like an agent of Azure DevOps So you can see what it’s doing, but it’s not a command line compile this thing for me Does that make sense? Cool >> If you are running over the build definitions and you are using the [inaudible] files share Can you migrate those to [inaudible] ? >> So the question was if you have it locally? >> No, it’s already defined those, including DevOps And you want to migrate and bring to the codes and make it part of checking and [inaudible] >> Okay. So the question is, if you already have that build definition right in YAML >> Then DevOps not [inaudible] sign >> In the Visual UI? Yeah, in VSTS Yes, sorry the question is to paraphrase was, if you already have that visual build editor, that visual build definition can you pull that into your source code? And yes, that’s the one I showed you just before where if you have that visual example, you can grab that job and view the YAML copy and paste that This doesn’t actually move though You have to create a new job for it Yeah so you would lose your history You can keep this around and then just remove all the triggers

So you have the history there and then going forward, you have the new build definition Now this is actually completed I’m going to move on So we’ve got this build definition, so we can see all of the stuff that happened And we can see the summary as well The good thing about the summary is that we’ve got this “Build artifacts published” section and I’m going to just start zooming in like this because I think that’s a bit easier So this is the “Drop folder”, this is the thing we uploaded to Azure DevOps We can look at the contents or download it But if we look at the contents directly, we can see that all we did really because we zipped it up and then push that up to Azure DevOps We now just have a “Zip file” which has our compiled node application That’s the thing that we want to deploy to Azure itself We can also see that it succeeded, we can look at the logs We can see the associated changes and that will give us a deep link all the way back into GitHub as well So we can see the “Commit” that made that change If we have things like unit tests, we can also get test results in there as well You can see analytics of how those tests have performed across the last few builds I don’t have any at the moment So that’s not going to give much Then there are extensions that can give you other things like Build Reports from WhiteSource which looks at your dependencies of your application to determine whether there are any vulnerabilities, for example So that is an extension that you can add to Azure DevOps to enable you to get that extra information as well But I want to deploy this now I’ve got my build, I’ve got my artifact, I’ve completed it, so I can click on this release button at the top and it will start to fill out this release definition for me Once again, I have templates that I can use I can deploy a Node App to Azure App Service, PHP, Python, Kubernetes cluster all sorts of stuff I’m just going to do a stripe Azure App Service deployment though So let’s apply that template Let’s just kill that for the moment It’s set up this pipeline where we’re starting with the artifacts, this is the artifact from the build We’re doing a continuous deployment So there’s a trigger on it to say every time there’s a new build artifact, a new result from my build Stop this process Then right now we have one stage which has one job and one task At the moment it’s waiting for me to give some more information So let’s just rename this to “Staging” Thank you. Let’s just rename this to “Staging” and we’ll change the tasks that are in there Now this will probably look familiar This is exactly the same engine as the build It’s basically a task runner that runs one task after another on a particular agent You can add more agents, agent jobs So you could run some on Windows, some on Linux You can add a deployment group job and I’m not going to go into this right now, but that’s the way you can deploy on-premises You can add a job which deploys to all of your web servers and then have 10 web servers in that deployment group It will run that task on all 10 of those machines Or an agent-less job If you just want to do something like coal and Azure API, you probably don’t need to run all of that stuff on an agent itself You can just run it straight from Azure DevOps The settings that it needs right now The Azure subscription that I’m using I’ve already set one up So there’s a subscription to where I’m deploying it to But if you don’t already have one set up, these are the available Azure subscriptions that are tied to the same account I’m logged in as So, there’s one for that subscription itself, there’s some for my CDA, my “Cloud” advocate groups, all sorts of stuff as well If I chose that, I could click the button to “Authorize” this and it would just set up a service principal which does the authorization scoped to that entire subscription, which I probably don’t want So I can look at the advanced options and restrict it to, for example, a resource group Say this release definition can only deploy the stuff in this resource group Which is a great way of reducing what we call your “Blast radius” If somebody manages to change this definition to run some cryptocurrency mining, they can only do it inside that resource group right? They’re not going to be out of bounce around your entire thing So let’s just choose the existing subscription I’m deploying a Web App on Windows and I’m just going to do that There is already an App Service setup for me called “AbleTailWindFrontEnd4Staging” When I’m zoomed in Chrome doesn’t like that drop-down So those are the settings that I’ve got for my staging environment I’m just deploying that application to that App Service But I don’t want to just go to staging, I want to go to production as well So let’s “Clone” that stage Now I have another one which has got the same task in it I’m going to call this “Production”

I’m going to wait and make one change to that task, and that’s really just changing it to the production one So I’m just going to deploy to a different App Service Now you might want to deploy to a different slot You might want to deploy to a completely different subscription for your production environment You have full control over this You may even want to run some scripts, some extra things Again you can add tasks either from me, out of the box or the marketplace or your own scripts and things like that So this is our pipeline at the moment, every single time a build completes and that’s a continuous integration build, we’re going to kick off a job to deploy to our staging environment and then automatically goes straight to production which is also not maybe the best idea So I’m going to add a “Pre-deployment condition” So these are conditions that you can add to give you a way of ensuring that the right stuff is working and so on before you actually push the production There’s a few different things that we can do here but I’m going to do the really basic one, which is the “Pre-deployment approval” So I’m going to enable one of those. I’m going to say I can’t spell anything at the moment even my own name Can somebody read my name tag for me So I’m going to say I have to approve this move to production It’s not going to go to production until I say that it can So we’re just going to leave it at that at the moment Every single time there’s new build, we’re going to go to staging and it’s going to wait for my approval and then go to production But other than just saying this is good to go, I’m not copying files around, I’m not doing anything manually myself Let’s save that We’ll go back to Azure DevOps, sorry, to our VS Code and we’ll make a change We’ll say “Tailwind Traders pipeline” Make that change Say “New title” “Commit push” Obviously I’m a hardcore developer so I’m not even going to compile this locally or try and work it, I’m just going to change stuff The good thing though is, if I broke it, we have this build which is going to fail hopefully or test will fail Right from the start I now have this process where I can commit bad code but know that it’s unlikely to make it to production This is part of the deploying cipher as well I want to build up this pipeline as much as I can to enable it to prevent bad stuff from getting to production Right now I’m not running any tests, so the only thing that’s going to stop it is if it doesn’t compile anymore or if I notice in staging it’s broken, I won’t prove it to go to production, which is a decent test right? But there’s some other things that I might want to do We’ll get to that in a second Let’s just go back to our builds and see if it’s kicked off a new one and there you go We’ve got a new title “Build” that’s running at the moment Checkout has succeeded, so this should be hopefully a lot faster than it was Now, we’re doing an npm install, which is usually really quick So an npm install, we’ll have that build definition We’ll have a new version of our application It’ll start kicking off our deployment to staging and then go all the way through to production So while that’s going, you have another another quick opportunity for questions. Yes >> So what is the limit of the artifacts and how many artifacts can be stored? >> So the question was, what’s the limit of the artifacts and how many artifacts can be stored If you’re using this way of uploading artifacts from your Build to just say throw them up and attach them to the Build Definition itself or the Build itself, I don’t think they’ve got a limit on it right now However, it’s going to depend on your retention policy So I’m not 100 percent sure on this, but I don’t think they restricted I think they just say, your retention policy basically means that these builds and the results of the Build only really stick around for maybe 30 days, or something like that If you’re using Azure Artifacts though, which I’m not at the moment, but Azure Artifacts is a bit more of a permanent way of doing it So you could instead of putting the artifact opposite and attachment to the build itself, you could put it up into Azure Artifacts and say, “This is my tailwind front end version 1.3, here’s the zip file,” and that will stick around for as long as you need it to in Artifacts There’s a feature in Artifacts, so originally it was supposed to be npm packages, Maven packages and NuGet packages, but there is also a new feature called universal artifact, which basically allows you to upload a bunch of files, give it a name and a version, and it’ll keep that as a version of whatever artifact you have So you can upload anything really I’m just going to skip to the release while we’re doing this and that’ll take a second There we go, there was a hand just there. Yes

>> Can you use any other artifact repository or any other Artifactory? >> The question was, can you use any other artifact repository or any other Artifactory? Yes. You can absolutely So uploading your build artifact to that artifact location So Artifactory or something like that, that would just require you to add a new task to your build definition at the end to say push this up to Artifactory or whatever In your release definition, and this is completed, so I’ll show you in a second But in your release definition, if you edited that, this artifact that we got here, we got this from our own Build But I could add a new Artifacts that comes directly from Azure Repos, GitHub, Team Foundation Version Control, Azure Artifacts, Azure Container Registry, Docker Hub, Jenkins If you haven’t built artifacts that is from for example Team City or Artifactory or something like that, there’s likely to be an extension in the marketplace which will add a new artifact type to here So when there is a new artifact or a version of a NuGet package in Artifactory, it will kick off a release and do that released there So yes, you can absolutely use an existing location >> Can you download it from here? No, this will be just in the release pipeline that it appears So I can see there’s a question there I’ll just do this for a sec We can say that it’s in staging, it’s waiting for my approval to production So let’s just quickly approve that and say, “Good to go.” Just before I hit that, let’s have a look at what staging looks like So this has the new one in it Production does not, it just has Tailwind Traders We have not updated in production yet until I do that approval I can defer it for later if I wanted to do it outside of business hours or something like that But let’s approve that and we’ll see that it will kick off that deployment to production So that’s in process now. Question? >> How much of this can you reuse when you’re use different public Cloud, say Alibaba in China? >> So the question was how much of this can you reuse if you’re deploying to say a different public Cloud? That’s going to depend a lot on your application However, your release definition, if you’ve already packaged up your node application or something like that and you just want to release it to a different Cloud, then that would just be a matter of changing your release definition itself In the marketplace, we even have things like tasks to deploy to AWS for example Now, I’m showing this one because it was actually the Microsoft team working with Amazon to get that task and those series of tasks out the door So cross Cloud collaboration So yes, you can generally do the same build You can generally do the same presteps and so on The actual deployment itself is likely to change, if you want to go to a different Cloud. All right So that should have hopefully gone to production Let’s just refresh this and production now has pipeline All right, cool. That’s a really basic one So we’ve basically got a build compiling We’re going to staging environment, we’re going to production environment after an approval But I’m not really banging the stuff that I mentioned right at the start about making sure that this is what people want I’ve just deployed a new feature I haven’t determined whether anybody wants this feature I don’t know if I’m delivering value yet So there were a lot of different techniques you can use to work out whether you’re delivering value One of those techniques is doing what we call canary deployments It’s similar to doing IP testing or doing roll-outs and things like that But the general idea is you deploy your change to a subset of your users, watch what they do, watch if it’s successful, make sure that they’re happy and if it’s right, then start rolling it out to everybody else So that’s a technique that I’m just going to show you now You can do this in different ways I’m just going to do it using a feature of app services called Slots, and I’m going to deploy to a Canary Slot, and then I’m going to deploy it to everybody else once that’s okay So let’s jump into Azure and we’re going to add a new slot to our production environment Now, this enables me to basically create a duplicate website or another website that I can deploy it, and then give some of that traffic to that environment Let me just refresh this So let’s do that again Jump to the TailwindFrontEnd4 code and there’s a section in deployment code, deployment slots Right now, I only have this production slot This is my production environment, but I can add a new deployment slot either “Add Slot” or “Click here” to get started

So let’s do that I’m going to enter a name We’re going to call it canary We don’t need to clone any settings I’m not really doing anything fancy, so let’s just add that This will give me another location that I can deploy to So our build is not going to change, we’re still compiling the application itself, but our release will need to change Instead of deploying strike to staging and then going into production, we’re going to deploy the staging I’m actually going to remove this pre-deployment condition, so it’s going to go straight to my first environment But I’m going to call this Production Canary Instead of deploying to that App Service directly, I’m going to deploy to a slot So in the task itself, you can say, “Deploy to a slot or an App Service Environment”, choose the Resource group that I’m in, and then choose the slot that I just created, that canary slot So now, this will deploy to the canary environment I also want to clone that environments So we deployed a canary, and I’m going to clone that and just say, “This is production for everyone.” I’m going to turn this slot thing off here, so we’re just going to deploy to the main application So we’re going to go to “Staging”, go straight to Production Canary, and I am going to put in a pre-deployment approval before we roll it out to everybody else So let’s just save that I need to do one more thing, I’ve created this slot but right now there’s no traffic going to that slot So let’s just close this Right now, 100 percent of the traffic is going to that production slot You probably wouldn’t want to do 50 percent, but I’m going to because there’s only one of me It makes for a terrible demo if I have to open 30 browser windows So I’m going to move 50 percent of that traffic to that canary slot So what it means is when somebody hits that production URL, half of them are going to go to the canary environment, half of them are going to go to production I can measure whether what I’ve delivered is successful in that canary environment before rolling it out to everybody else So let’s just kick off a change, and then I want to explain a couple of other things about this So let’s just make a change, canary, commit “Push”, make sure that actually kicks off a build I didn’t say that right go So that will pick up the change in a second, start a new build and start that process again, going to staging and canary, and so on So I did this using slots, you could easily do it with a load balancer, something like that There are some really cool tools out there One of the ones that I recommend and it’s not free but it’s really good, is called LaunchDarkly It allows you to segment your traffic based on pretty much whatever you want It’s a feature flag as a service tool as well So you can have some code in your application to say things like, “Go and get this particular flag.” So in this case, it might be a flag called main page title, for example So go and ask LaunchDarkly, “Do I turn this flag on or not? Do I give somebody the new page title or that I give them the old one?” Then in LaunchDarkly, you can segment that person or that visitor based on whatever you want So you could say, “If the traffic is coming from the Netherlands, then give them the new page.” Or “If this person belongs to a particular group of elite users, give them the new page,” and so on So you can start rolling this stuff out based on feature flags as well Right now I’m doing it naively, I’m just saying 50 percent of them go to this new location Facebook famously does this all of their stuff as well, they roll it out geographically So when they make a change, they will roll it out to based on time zones, they roll it out to New Zealand first, and then along all of the different time zones So by the time it gets to the US, it’s been tested by a lot of other countries, which is just interesting. All right So the good thing about that though as well, is if you deploy it out to New Zealand and then New Zealanders start complaining that it’s not working or whatever, you can turn that flag off again and you’ve only annoyed New Zealanders, which is fine So you can roll that back and then go back to the drawing board, and so on This can be really handy as well for people who are asking for a new feature, your customers who are asking for new feature, but, and I know the developers in the room are likely to be familiar with this, they ask for a particular feature but it’s not exactly what they wanted When you deliver it, they are like.”Oh, it’s what we wanted but it’s not really right.” So you could deploy this change just to those customers,

and then work with them to make sure it is right They’re testing it in production for you, but nobody else has affected, just those customers themselves So it’s a really good way of actually verifying that you’re delivering value before you deploy it out to production for everybody else So this is clearly one of the slightly, slow ones, I’m going to be at 66 percent for a while So I want to just talk about one of the other things that you can do here So we in here, we just deployed a single node application to the front-end to an App Service In general, you probably have much more complexity in your application You have a database in the back-end, you might have a second application, you might have some microservices that you want to deploy maybe at the same time You might have a number of different projects that need to be compiled So here’s an example of the Tailwinds, and this is the AllUp one So we actually have an inventory service to this is another repository comes from somewhere else, and it’s a.NET Core application, so we’re doing a.NET restore We’re doing some Bash Scripts, it’s.NET Core, so we’re still running this on an Ubuntu agent, I believe. Yeah, I know We’re actually running it on Hosted VS2017, but we’re still running Bash because WSL allows us to run Bash on Windows So we’re doing some.NET stuff, we’re running some tests, we’re doing some functional tests, we’re building a Docker image, and then we’re also defining an ARM template to define the environment that this runs onto, and then we’re uploading that as an artifact, so that’s one service, there’s another service which is building a Docker image and using Helm to deploy charts, so we can deploy Kubernetes We’re using the front-ends, this is the one that we’ve just seen, so this is the NPM application We’re even doing a mobile app for iOS So this one actually uses a Hosted macOS agent pool, so we’re building it on a Mac from Azure DevOps to deploy to mobile phones, to iOS phones We’re even doing things like installing provisioning profiles from Apple certificates, and things like that Then we’re copying files to publish directories, we’re uploading them, and so on So the result of this is that we get several artifacts, we’re building each thing individually and saying these are the artifacts we want It means that when we do our deployment, we have this one drop location which contains lots of different artifacts, but we have parallel pipelines for released So this is one way we could do it, we might want to tie them all in so they all got released at the same time But here, we’re deploying the imagery service, we’re doing a BlueGreen deployment, which basically means stand up a new environment, deploy to that environment, so I have two environment, deploy to one, and then if it works, switch the traffic to that one, then the next time you deploy to your green environment and switch the traffic back, and next time you deploy to your blue environments, switch the traffic back, it’s another technique for maintaining up time Then we’re going to production Product service is going to a Dev staging and production environment Our web front end is going to staging Prod A and then Prod B So we’re doing kind of a canary deployment there Our iOS App is going to a Dev environment, a Beta environment using test flight to deploy to our Beta testers, and then going to the store We have a lot of freedom in what we’re actually doing in our deployment We can deploy all of that kind of stuff. All right We’ve finished that one, so hopefully we’ll be able to see that We’re deploying two staging at the moment Let’s follow that along, and we have deployed two staging Now we are cued to deploy to the production canary environments Staging if we refresh, should look like this, we have canary in there, which is great We’ve deployed a staging Production now is going to be a bit more complicated Production right now when I hit it from this browser is showing me the old website We are deploying to the canary one at the moment, so I just happen to know that this one is hitting the real production site When this deploys to canary, this is not going to change, this production side is not going to change But if I hit it from a different location, a different device something like that, I’m going to end up getting that canary site Let’s just wait until this finishes. There we go We’ve got a deployment to staging, a deployment to production canary, and it’s waiting for my approval to go to production Here, when I hit “Production”, it’s not refreshing and I’ve had that problem before Let’s try this I’m sorry that is the production one. So that is correct Sorry. That’s the existing production site I want to hit it again. Let’s try this Let’s try doing it in Safari We get the same thing Cool. Let’s do a incognito Safari

This is the problem with having just 50 percent of the traffic It’s non-deterministic which means that these demos can go really really well Now we’re hitting the front end website Okay. But we’ve got that change I’ve hit the production URL from a Chrome browser, and then I’ve hit the production URL from an incognito Safari browser or private browsing Safari browser, and I’ve got a different result I can look at the people who are hitting this new location and find out whether there are any complaints about it If there or not, I can just approve that, say this looks good That will roll out to everybody Production will start seeing that new feature that I just deployed as well This gives me another way of making sure that what I’m deploying is not just working but it’s also valuable for people I can determine whether the application that I’ve just deployed is doing what people wanted to do There’s one more thing I want to do I mentioned before, I made a comment that comes from my boss, never send a human to do a computer’s job This is a manual approval for me to look at staging or look at that production canary environment and say, this needs to go to production I don’t want to do that There are ways that I can determine whether it should go to production without human intervention Let’s just take off this pre-deployment approval I’m going to add a deployment gate Actually, I’m not going to do that here I will just do it here because I need to show you the end purpose anyway, we’re running out of time I can add a deployment gate and this is like an automated approval process before it will go to production, and there are a number of different gates that I can use, that come out of the box I’ll start from the bottom I can do a security and compliance assessment over the resources in Azure to make sure that they are meeting my security requirements, and if they’re not, I will not deploy this application to production I can check for this stuff before going on If it does comply, then I can move on to the next gate or the next approval or I can just go straight to production I can Query Work items If I’m using Azure Boards to work out the work that I’m doing, and maybe not deployed a production if there is an open severity one issue for my application I probably want to fix that first I could have a look at Azure Monitor Alerts I have a look to see whether there are exceptions or more exceptions than I expected, or the performance has decreased or something like that Then these last two give you pretty much full reign over whatever you want to do to verify that your application is working You can hit a “REST API” and make sure that, that gives a correct response or hit an “Azure Function” By way of example there, here is an example of something that Abel did He worked at a hospital or did some work for a hospital where they needed that a hard and fast rule that you had to have a document signed before he could go to production He convinced them to use DocuSign As this gate so it goes to a staging or pre-production environment, and it will hit “Azure Function” which hits the “DocuSign API”, and has a look to see whether that document has been signed Not signed there, not signed five minutes later, was signed five minutes after that, all right go straight to production Hands off on a day-to-day basis but you’re still making sure somebody is physically signed that document There’s another one as well that he’s worked on where he wrote an extension for Dynatrace which is a performance monitoring tool If Dynatrace has a look at what’s deployed right now and says the performance has dipped by whatever threshold I care about, this is not good enough to go to production This application is now too slow It doesn’t hit our thresholds for how fast that needs to be, so just don’t go to production In this case of course, it was fine so we went to production But in this one that gate did not pass We had too many exceptions or it didn’t perform well enough, so we just stopped it from going to production Again, really hands off this stuff as well There’s a lot more that you can do here to make sure you’re deploying not only faster but safer as well We’re running out of time and I have to actually go to a session straight after this But at 2:00 PM in the Hub near Experts Center, I will be standing there answering questions I have a pile of stickers as well, if you want to come and grab them, that’s 2:00 PM today If you want to look at this stuff right now, Azure DevOps docs has some amazing walkthroughs of how to do all of this stuff There is also another document called the DevOps Resource Center and it’s not just Azure DevOps itself, it’s DevOps in general and Azure in general These slides are as well are available so I can see some people taking photos This is the one to take a photo off

but this applies for every session as well Aka.ms.MyMSIgniteTheTour will get you all of the session presentations and things Then your session code or the code that we use for all of these learning paths is on GitHub as well You can go and have a look at those whenever you want Make sure you fill out the feedback forms that’s really, really valuable to us as well I do have to go to another session, so I can answer questions in the Hub at 2:00 PM today Other than that, thank you very much for your time I hope you have a great rest of your day [MUSIC]