 Hi, I'm Donovan Brown, a Senior Program Manager for DevOps on the Visual Studio Cloud Services team. In this video, I'm going to show you the improvements we've made to release management. We're going to begin with a quick overview of some of the notable changes in the system and follow that up with a full demo and finally share some additional resources. Release management is completely new. We have replaced the old WPF client with a new rich web interface where you can author, queue and monitor your releases. We have also made the system highly extensible and even open sourced our task library. Release management allows your team to fully automate the deployment and testing of your application to every environment. No longer will you have to manually copy and edit files to deploy your application. Release management can handle any binary and deploy it to any platform. Release management is now fully multi-platform. You can now run your release natively on a Mac, Linux or Windows. You can release from Team Build or third-party systems like Jenkins. Deploy .NET, Java and Node.js applications in the cloud or on-prem. You can even test your application during your release with UI tests like Selenium, CodedUI, Web and load test. Now let's see release management in action. For the purpose of this demo, we're going to assume we have an application in version control for which we have enabled continuous integration. The application happens to be an ASP.NET MVC application with an accompanying UI test we would also like to execute during our release. We're going to implement continuous delivery by having release management deploy our application into Azure. Currently I'm on my Azure portal and as you can see I don't have any web applications. If I attempt to visit the page in which we're going to deploy to, you can see that it's a 404. I'm going to show you just how easy it is to deploy to Azure using release management. To begin, I simply need to create a new release definition. Release management comes with templates that know how to deploy different types of applications into Azure. We want to use the Azure website deployment. When I do this, it's going to create all the tasks that I need to to deploy and test my application into Azure. I simply need to select what subscription I would like to deploy to. The name of the application and where in the world I would like that website to exist. I'm also going to go and set the test category attribute of my test test to make sure it only runs my UI test. Now I can go and change the name of this environment to something more appropriate like dev. And if I know I'm going to do the same thing in dev that I'm going to do in QA, I can simply clone this to create my other environment. I will call this one QA. And then simply update the task here in QA to make sure it points at my QA environment. Finally, I will duplicate it a third time so that I can have a production environment. Before I enter and leave my QA environment, I would like to have an approver assigned. So I can simply assign an approver so that I get notified before the tool attempts to deploy into my environment and also before it releases my code to the next environment. Finally, I need to link my release to a build definition. So I happen to have CI already set up, simply link these together and now I'll give your release a name. We'll just call this connect. Now I can save and simply start a new release. I get to choose exactly which environment I would like to deploy to and it will take me through dev, QA and production and halting at the points where I asked for there to be an approval. Simply click on create and from here I can start to go see and monitor my deployment. As you can see, we get real-time logs from our agent letting us know exactly what it's doing on the environment. While this release is running, let me go talk to you about some other features that we have. One of which, if we go back to our connect definition here, is we have configuration variables that allow you to set information that's specific to your release and we can even encrypt this information if we need to. These variables will apply to your entire release definition. You can also set up triggers. These triggers will allow you to have continuous deployment to where as soon as the developer checks in code, this release will be triggered and it will try to run all the way into production. If I wanted to stop at a earlier, I can simply choose that stage instead. I can also define additional artifacts should I need to and one other thing I want to point out is when we're defining our task, we have an enormous task library that we can use to deploy our applications. As you can see, we have integrations with Chef, we have integrations with Docker, you can deploy to Tomcat, your DacPak files. Anything that you can do from a command line, you can do from our release system and we can do that using a batch script, command line, PowerShell, or even a shell script because release management is multi-platform. You can run your releases on a Mac, you can run them on Linux, or you can run them on Windows as well. Not only can you set up variables for your entire release, but you can actually come to each environment and set up variables there as well. As you can see, those variables can be encrypted. At this point, we should be able to go back and see what our release is running like. Let's go back to releases. As we can see, we have a release who is waiting for an approval. If I were to go back now to this website and press F5, we should be able to see our release. I can go back to our portal here while that's loading and verify that I now have a website actually out in Azure. Just that simply, you can deploy an application directly to Azure using release management. Now that we've successfully deployed to our Dev environment, let's go and audit our release. By double-clicking on it, it brings me to the Summary page. The Summary page allows me to see all the environments, which ones we've successfully deployed to, gives me even access to our test results. So I can go back here and quickly see if my UI test were successful or not. I can also see any build artifacts that were associated with it, who caused it, and also go back in and see the approval that's pending. By coming in here and saying everything looks good, I am giving release management permission to leave the Dev environment and enter the QA environment. Release management will rinse and repeat this process until we've made it all the way into production. I hope you enjoyed that quick overview of release management. Here are some additional resources that you can use to learn more about release management. I would also recommend that you follow me on Twitter and my blog for the latest information. Until next time, I'm Donovan Brown.