This course will help get your code built when changes are committed, then get your IIS applications deployed using automated steps from VSTS or TFS! You'll see examples of this for ASP.NET Core and Framework sites as well as WCF apps.
Establishing solid build and release definitions for IIS-based .NET applications is a critical building block for true continuous delivery. In this course, Continuously Deliver IIS-based .NET Applications, you'll get into lots of the practical details that need to be addressed when delivering real applications via build and release definitions. First, you'll discover how .NET applications properly handle packages, shared library references, and configuration. Then, you'll try various flavors of ASP.NET applications and WCF services. All of these topics will be accomplished within Visual Studio Team Services (VSTS), and the same concepts would apply in various flavors of Team Foundation Server (TFS). Next, you'll learn about the build and release definitions within VSTS that will include most of the tasks and steps needed. Lastly, you'll take a close look at using PowerShell to perform custom activities when the predefined tasks don’t cover everything you need. By the end of this course, you'll not only be able to get your IIS applications deployed using automated steps from VSTS or TFS for ASP.NET Core and Framework sites but use Powershell for custom requirements as well.
Course Overview Hi everyone, my name is Erik Dahl, and welcome to my course: Continuously Deliver IIS-Based. NET Applications. I'm a principal architect at RealPage. Continuously deploying websites based on committed code changes can vastly simplify the overhead involved in introducing change for your web applications. In this course, we're going to explore some aspects of getting IIS applications built and deployed using continuous deployment techniques, and will be covering ASP. NET Core and Framework websites, along with IIS hosted WCF Services. Some of the major topics that we'll cover include: setting up build definitions that include multiple projects and result in published artifacts. Setting up release definitions that can deploy those artifacts as IIS websites and applications, with environment-specific settings. Triggering both the builds and the releases automatically, and using PowerShell to complete the automation process where canned options fall short. By the end of this course, you'll know how to set up build definitions that include multiple. NET projects, how to safeguard specific variables you want to keep secret during environment deployments, how to set up release definitions that can deploy all of your IIS- based projects, how to set up approval requirements for those deployments, and how to use PowerShell in deployment steps for some common certificate and IIS-related tasks. Before beginning the course, you should be familiar with some basic IIS concepts, and general concepts around ASP. NET web applications. I hope you'll join me on this journey to learn about automated IIS deployments, with the Continuously Deliver IIS-Based. NET Applications course, right here at Pluralsight.
Choose Triggering Mechanisms to Enable Continuous Integration and Delivery So far in this course, we've gotten builds set up that can build our IIS applications and publish the artifacts from those builds. We've also gotten a release definition created that can deploy ASP. NET Core and Framework websites, along with WCF Service projects. Erik here again, and in this module, we're going to update both our build and release definitions to happen automatically when we commit code changes. We've already done most of the heavy lifting involved in this course. Getting clean builds is a huge first step, and then well-defined release definitions that can get your code running where you want it to is also huge. Figuring out how we want these activities initiated or triggered should be relatively simple. Let's dive in and get it rolling. The first component of this module will be to fully automate our build processes. To do that, we'll explore the different triggering options available to us. From code change triggered, known as continuous integration, scheduled triggering, and even being triggered by the completion of another build. After looking at options, we'll update our build definition to use a CI-based trigger and verify that it works as we want. Then we'll shift our focus to release definitions. We'll look at the distinction between release creation triggers and environment and deployment triggers, and the options around them. We'll then look at the options specifically available as pre-environment deploy conditions, followed by options we have for post-deployment conditions. Then we'll update our release definition to be continuously deployed to our test environment with a simple approval. Should be fun. Let's go get started by looking at builds.