Exam Objectives
Create an IIS install package; deploy to web farms; deploy a web application by using XCopy; automate a deployment from TFS or Build ServerQuick Overview of Training Materials
Exam Ref 70-487 - Chapter 5.1
[MSDN] How to: Create a Web Deployment Package in Visual Studio
[MSDN] Using Web Deploy for Web Farms (2009)
[MSDN] Deploy an Application to a Web Farm
[MSDN] How to: Create a Web Deployment Package in Visual Studio
[MSDN] Using Web Deploy for Web Farms (2009)
[MSDN] Deploy an Application to a Web Farm
[MSDN] Introducing the Microsoft Web Farm Framework
[MSDN] Xcopy
[MSDN] Walkthrough: Deploying an ASP.NET Web Application Using XCOPY
[MSDN] How to: Create an Automated Build and Deployment Solution with TFS
[MSDN] Build and Deployment Automation Case Study
[Blog] Using Windows Azure VMs to Publish and Synchronize a Web Farm
[MSDN] Xcopy
[MSDN] Walkthrough: Deploying an ASP.NET Web Application Using XCOPY
[MSDN] How to: Create an Automated Build and Deployment Solution with TFS
[MSDN] Build and Deployment Automation Case Study
[Blog] Using Windows Azure VMs to Publish and Synchronize a Web Farm
A "Web Deployment Package" is a set of files that can be used with the Web Deploy tool (msdeploy) to deploy the web project into the configured IIS website. To create an IIS Web Deploy Package in Visual Studio, navigate to Build => Publish Application:
If you haven't already created a "Publish Profile", you'll need to set one up. This really is just a handful of properties that define there the files are created and what settings are used with IIS (for our purposes, other profiles may have connection strings and other settings baked in). Select the "custom" publish target.
Select "Web Deploy Package", choose the local directory where the files are created, and specify the site name. The site name must match how the site is configured in IIS, or the Web Deploy tool will throw an exception.
This will create the following files in the specified directory. The <solution>.deploy.cmd file is a batch file that will use msdeploy (part of the Web Deploy extension) to install the files into IIS.
Oops... I didn't specify the deployment package right. You have to be sure that the "Site Name" exactly matches the complete website name, including the "Default Web Site" bit:
The installation batch command takes one required parameter, and a number of optional ones. You are required to specify either /T or /Y to test the deployment or execute it (respectively). If you installed the Web Deploy remote agent on the target machine, you can deploy remotely using the /M:<machine name>, /U:<username>, and /P:<password> flags:
As with any app deployed to IIS, you'll need to make sure that the app pool is using the correct version of .NET, and I ran into a number of assemblies that weren't being copied over for some reason. I was eventually able to get it to run, but it was a pain. I hate IIS...
If you haven't already created a "Publish Profile", you'll need to set one up. This really is just a handful of properties that define there the files are created and what settings are used with IIS (for our purposes, other profiles may have connection strings and other settings baked in). Select the "custom" publish target.
Select "Web Deploy Package", choose the local directory where the files are created, and specify the site name. The site name must match how the site is configured in IIS, or the Web Deploy tool will throw an exception.
This will create the following files in the specified directory. The <solution>.deploy.cmd file is a batch file that will use msdeploy (part of the Web Deploy extension) to install the files into IIS.
Oops... I didn't specify the deployment package right. You have to be sure that the "Site Name" exactly matches the complete website name, including the "Default Web Site" bit:
The installation batch command takes one required parameter, and a number of optional ones. You are required to specify either /T or /Y to test the deployment or execute it (respectively). If you installed the Web Deploy remote agent on the target machine, you can deploy remotely using the /M:<machine name>, /U:<username>, and /P:<password> flags:
As with any app deployed to IIS, you'll need to make sure that the app pool is using the correct version of .NET, and I ran into a number of assemblies that weren't being copied over for some reason. I was eventually able to get it to run, but it was a pain. I hate IIS...
Deploy to Web Farms
Once again the exam ref proves to be completely useless... this section basically is just a intro level explanation of what a web farm is... smh. While it is important to account for session management, server affinity, caching, load balancing, and myriad other concerns when designing a web farm... that isn't the objective.
Microsoft has a Web Farm Framework extension for IIS, which first entered beta in 2010 and is currently in version 2.0, but is only supported for IIS versions 7 and 7.5 (thread on IIS forums seems to support the rumor that WFF development has ceased). The Deploy an Application to a Web Farm article on MSDN is based on the AppFabric samples, which are no longer available for download (probably owning to the fact that AppFabric is discontinued). This basically means that you are on your own to set up an IIS webfarm. Web Deploy can still be used for deployments in this scenario.
Wade Wenger's blog post on using Azure Virtual Machines to create a web farm offers up a good example of how one might build a web farm from scratch. The Windows Server image with IIS is built from the ground up then saved as a reusable image. Virtual machines are then created from this image for use in the web farm. Deployment is done by using Web Deploy to update one machine, from which the other machines pull updates.
Another article on MSDN explains how to create a load balanced IIS web farm using availability sets. The author doesn't go into details on deployment, but with Web Deploy installed on the individual machines it would be possible to updated them using the Web Deploy Package (although for large farms you'd want some scripting around that). He does point out that Cloud Services and Azure Websites based deployments are much simpler to scale, as it is just a matter of dragging a slider.
Microsoft has a Web Farm Framework extension for IIS, which first entered beta in 2010 and is currently in version 2.0, but is only supported for IIS versions 7 and 7.5 (thread on IIS forums seems to support the rumor that WFF development has ceased). The Deploy an Application to a Web Farm article on MSDN is based on the AppFabric samples, which are no longer available for download (probably owning to the fact that AppFabric is discontinued). This basically means that you are on your own to set up an IIS webfarm. Web Deploy can still be used for deployments in this scenario.
 |
| Who wants to play with obsolete tech? Anyone? Bueller? |
Wade Wenger's blog post on using Azure Virtual Machines to create a web farm offers up a good example of how one might build a web farm from scratch. The Windows Server image with IIS is built from the ground up then saved as a reusable image. Virtual machines are then created from this image for use in the web farm. Deployment is done by using Web Deploy to update one machine, from which the other machines pull updates.
Another article on MSDN explains how to create a load balanced IIS web farm using availability sets. The author doesn't go into details on deployment, but with Web Deploy installed on the individual machines it would be possible to updated them using the Web Deploy Package (although for large farms you'd want some scripting around that). He does point out that Cloud Services and Azure Websites based deployments are much simpler to scale, as it is just a matter of dragging a slider.
This is one of the few times that I'm going to skip doing some kind of demo. I hate dealing with IIS and I'm pretty sure building a web farm from scratch is probably out of scope for the exam...
Deploy using XCopy
XCopy is a command line tool for copying files and directories. According to the Wikipedia page, the name means eXtended copy, which implies it is a more robust version of the copy utility. Starting with Vista/Server 2008, another copy command, "Robocopy", is also available, with some users reporting better results when copying over a network.
I did a quickie deployment, working through the walkthrough article, and there really isn't much to know about using XCopy. It didn't want to work with the network address, so I had to map a file system share to the deployed folder, but other than that it was just a simple "copy" operation...
I did a quickie deployment, working through the walkthrough article, and there really isn't much to know about using XCopy. It didn't want to work with the network address, so I had to map a file system share to the deployed folder, but other than that it was just a simple "copy" operation...
Automate a Deployment from TFS
Visual Studio Team Services is the cloud hosted version of the on-premise Team Foundation Server, and both offer similar capabilities with regards to automating build and deploy. Many of the current buzzwords around the build/deploy pipeline (Continuous Integration, Continuous Delivery, and DevOps) are thrown around in the documentation. I'm going to focus mostly on VSTS, because that's what I have access to and that seems to be the future of the platform for Microsoft (watch, I'll be eating these words in a year or two lol).
The top level organizational unit in VSTS is an "account". These are created from your visualstudio.com profile (you can have multiple accounts):
Under an account are multiple "Projects", which may contain multiple source control repositories. VSTS supports Git and TFVC repos, but a given project will only support one of the other. When you initialize a new Git repo, you have the option of creating a README file from a template (in MarkDown), as well as a .gitignore file tailored to your IDE. The hosted Git repo should be pretty easy to navigate for anyone already familiar with GitHub or BitBucket.
Once you have a code repo, you can create a build definition off of it. Two tabs to the right of the "Code" tab is "Build and Release", which is where all the CI/CD tasks are managed. A Build definition gets the source from the repo it's pointed at and runs a series of tasks (which may or may not have anything to do with the code, actually). These build tasks are run on a build agent, which may be "Hosted", meaning it runs in Microsoft's cloud, or it can be a "Private" build agent that lives inside you company firewall (I explain how to set one up in a previous post).
Build templates exist of a wide variety of project types, or you can start with an empty template and build it up from scratch. If the task you need isn't available out of the box, a number of add-ons are available from the Marketplace (the Run Inline Powershell task has proven to be quite valuable in my own build definitions).
A couple positions over from "Tasks", you'll notice there is a sub-menu for "Triggers". This is where we can configure the build to start automatically any time there is a change in source control (which is a foundational concept when doing Continuous Integration). It is also possible to run a build on a schedule:
Releases work much the same way. You first define which artifacts are to be pulled into the release (generally the build), then define a set of environments with tasks to go inside those environments. Automatic builds can be triggered by new artifact creation (as in an automated build from source control) or by a schedule. Release can also be set up with pre- and post- approvals for each environment (useful if business requirements require sign off for code promotion):
The top level organizational unit in VSTS is an "account". These are created from your visualstudio.com profile (you can have multiple accounts):
Under an account are multiple "Projects", which may contain multiple source control repositories. VSTS supports Git and TFVC repos, but a given project will only support one of the other. When you initialize a new Git repo, you have the option of creating a README file from a template (in MarkDown), as well as a .gitignore file tailored to your IDE. The hosted Git repo should be pretty easy to navigate for anyone already familiar with GitHub or BitBucket.
Once you have a code repo, you can create a build definition off of it. Two tabs to the right of the "Code" tab is "Build and Release", which is where all the CI/CD tasks are managed. A Build definition gets the source from the repo it's pointed at and runs a series of tasks (which may or may not have anything to do with the code, actually). These build tasks are run on a build agent, which may be "Hosted", meaning it runs in Microsoft's cloud, or it can be a "Private" build agent that lives inside you company firewall (I explain how to set one up in a previous post).
Build templates exist of a wide variety of project types, or you can start with an empty template and build it up from scratch. If the task you need isn't available out of the box, a number of add-ons are available from the Marketplace (the Run Inline Powershell task has proven to be quite valuable in my own build definitions).
A couple positions over from "Tasks", you'll notice there is a sub-menu for "Triggers". This is where we can configure the build to start automatically any time there is a change in source control (which is a foundational concept when doing Continuous Integration). It is also possible to run a build on a schedule:
Releases work much the same way. You first define which artifacts are to be pulled into the release (generally the build), then define a set of environments with tasks to go inside those environments. Automatic builds can be triggered by new artifact creation (as in an automated build from source control) or by a schedule. Release can also be set up with pre- and post- approvals for each environment (useful if business requirements require sign off for code promotion):
VSTS is free to use for up to 5 "Basic" users and an unlimited number of Visual Studio subscribers. Additional licenses run about $6 each (as of this writing). Authentication uses either Microsoft accounts or Azure Active Directory (though this is an strict either-or proposition). With AAD, it is also possible to use group based permissions (though every individual who uses the service will consume a license).
One of my few complains about the service is that settings, particularly security settings (permissions) are spread all over the place. Builds and Source Control have separate permission pages from the main project settings, which are separate from the account level settings. It can get pretty confusing:
 |
| Account Level Settings |
 |
| Build Permissions |
 |
| Version Control Permissions... oh my! |
No comments:
Post a Comment