Tải bản đầy đủ
Objective 5.1: Design a deployment strategy

Objective 5.1: Design a deployment strategy

Tải bản đầy đủ

These types of deployment are referred to as XCopy deployments. XCopy is a DOS command that stands for extended copy. It enables you to copy multiple files at once to a target
destination. Today, the name XCopy is often used to describe a manual deployment. As you
can understand, these types of deployment are useful only when your application has no
special installation requirements, such as modifications to the registry or other files that are
located outside of your application folder.
The XCopy DOS command has the following syntax:
xcopy /I /S /E

The /I option indicates that you are copying a folder. The /S option specifies that you want
to copy all subdirectories (and /E indicates to copy subfolders even if they are empty). By issuing this command, the whole content of the folder will be copied from source to target.
The XCopy command has a lot of options that you can use to configure what should be
copied. For example, the /d option specifies that only files that are newer should be copied.
When regularly updating your website, the /d option can save you time by updating only the
files that you have changed.
MORE INFO  XCOPY SYNTAX

For an overview of all the XCopy options, see http://www.microsoft.com/resources/.

Configuring IIS
The first time you copy the files for your website to your server, you need to configure the
website. This is done in Internet Information Services (IIS). IIS is a web server that you can use
to host a wide range of applications on Windows, such as ASP.NET projects and WCF Services.
You need to tell IIS where the folder for your website is located and how it should be made
available to users.
MORE INFO  INSTALLING IIS

By default, IIS is not installed. For the steps to configure IIS on Windows 8 or on Windows
Server 2012, see http://www.iis.net/learn/application-frameworks/scenario-build-anaspnet-website-on-iis/configuring-step-1-install-iis-and-asp-net-modules.

Assume that you have created an ASP.NET Model-View-Controller (MVC) application that’s
located at C:\Development\MyApp, and you want to copy it to C:\inetpub\wwwroot\MyApp.
To do this, run the following XCopy command from a console:
xcopy /I /S C:\Development\MyApp C:\inetpub\wwwroot\MyApp

You open Internet Information Services (IIS) Manager (see Figure 5-1) to configure a new
website that points to this directory.



Objective 5.1: Design a deployment strategy

CHAPTER 5

363

FIGURE 5-1  IIS Manager

For the exam, you need to know how to create and configure a website. You take the steps
described here to create a website. Remember to give the site a name to distinguish it from
other sites and point the website to the folder on your hard drive (for example, C:\inetpub\
wwwroot\MyApp).
Normally, you assign a host name to your site that can then be used by IIS to map incoming requests on port 80 (the default port for HTTP traffic) to your website. You can also
change the port number to something else, such as 81, and leave the host name empty so
you can reach your site on the unique port number. Figure 5-2 shows the final configuration
in IIS.

364

CHAPTER 5

Deploying web applications and services

FIGURE 5-2  Configuration for adding a new website in IIS

After you configure your website, you can reach it by opening a browser and going to
http://localhost:81. This sends a request to IIS that maps the port number to your configured
website.
After you have configured your website, you can continue modifying and extending your
code and then use the XCopy command to deploy a new version.
MORE INFO  CONFIGURING IIS

This is only a basic introduction to IIS, which is a complex product with a lot of options. On
the exam, you aren’t likely to be tested on specific IIS knowledge, but if you want to know
more about how to configure IIS, see http://www.iis.net/.

Preparing a website for deployment
While the XCopy command is running, IIS notices the file changes and starts refreshing your
website. This can lead to errors when your website will respond to requests while the deployment is only partially completed.
To avoid showing errors to your users, you can take your website temporarily offline
while your deployment is running by placing a file called App_offline.htm in the root of your
website. You can use this file to show a nice message to any user visiting your site. When the



Objective 5.1: Design a deployment strategy

CHAPTER 5

365

deployment is finished, remove this file so subsequent requests can be processed. Figure 5-3
shows an example of what this might look like.

FIGURE 5-3  An example App_offline.htm file

Your application domain can restart a couple of times while your website is being updated.
Fortunately, ASP.NET offers a web.config setting that you can use to minimize the number
of restarts. By adding the waitChangeNotification attribute to your web.config file, you can
specify the number of seconds to wait before the application domain is allowed to restart:



waitChangeNotification="5" />



Tooling support for XCopy deployments
Using XCopy from the command line is probably not the preferred way of deploying your
website. Besides not having a friendly user interface, another disadvantage of using XCopy
is that all files in your project folder are copied to the destination folder. Fortunately, Visual
Studio helps you with a couple of tools that can help you deploy your website in an easy way.
One such tool is the Copy Website Tool, which you can use when working with website
projects. The Copy Website Tool enables you to copy files between a source and target website. The tool supports the following features:
■■
■■

■■

■■

366

You can copy source files to the target site.
You can copy files by using any connection protocol that is supported by Visual Studio,
such as a local IIS, remote IIS, FTP, and HTTP (requires FrontPage Server Extensions).
You can choose which files to synchronize from your source to the target server, or vice
versa.
You can automatically copy the App_offline.html file to the root of your website when
it starts deploying and remove it when it finishes.

CHAPTER 5

Deploying web applications and services

As you can see, deployment this way is easy, but when your application grows, these
XCopy deployment styles have their limits. This is when you want to look at another tool: the
Publish Website tool (for website projects) or the Publish option (for web application projects).

Creating an IIS install package
Released in 2009, Web Deploy enables you to create a Web Deploy package that contains not
only the website that you want to publish but also other configuration options such as database settings, IIS settings, registry options, or assemblies that you want to put in the global
assembly cache (GAC).
The Web Deployment Framework helps you by simplifying your deployment process. It
enables you to deploy from Visual Studio 2012, IIS, the command prompt, and Windows
PowerShell. It also helps you when you work with complex environments such as a web farm,
where you can synchronize different web servers using Web Deploy.
The Web Deployment Framework has a set of built-in providers that enable you to configure the machine you want to deploy to.
When the deployment of your application becomes increasingly more complex, the Web
Deployment Framework is the tool that you want to use.
MORE INFO  WEB DEPLOY PACKAGES

For more information on Web Deploy packages, see Objective 5.5, “Create, configure, and
publish a web package.”

Automating a deployment from TFS or Build Server
A couple of years ago, it was not unusual to ship a new version of a product only once every couple of years. At the start of a project, you would come up with a big list of features
that the customer wanted, and you would start developing. The biggest problem with this
approach is that it’s hard for a customer to know upfront what he really wants, so a lot of
projects didn’t make their deadlines or didn’t deliver a product that fully solved the needs of
the customer.
Software development is slowly changing to resolve these types of issues. Agile software
development, although sometimes used as a buzzword, is becoming the norm. Agile methods
are based on an iterative and incremental process. Instead of doing a lot of design at the start
of a project and delivering only when everything is ready, you start working in shorter periods. This enables you to evolve your requirements and the solution you are developing while
the project is maturing.
Agile methodologies such as eXtreme Programming (XP) and SCRUM describe a process in
which you engage the customer in your development process by showing them the progress
you are making not just at the end of your development process but also continually during
development. This requires a new way of deploying applications. If you want to show your



Objective 5.1: Design a deployment strategy

CHAPTER 5

367

application to your customer every two weeks, you can’t spend days manually configuring
and updating your servers. Instead, you want to automate the way your applications are deployed. Your software should be ready to be released at any time.
This idea is called continuous delivery. Of course, moving to such a process requires changes both in how you use your technology and in how you work. Because of this, a new culture,
DevOps (Developer Operation), is emerging. In a DevOps culture, everyone works collaboratively on making sure that the application is always ready for deployment.
You can even go one step farther and move to continuous deployment, in which every
change that is made by a developer on the team gets automatically deployed to the production environment. Of course, this is not something that every business wants, but having such
a quick feedback loop can be useful. A continuous feedback loop exists between defining,
developing, and operating your application.
EXAM TIP

The exam states that you should know how to automate a deployment from TFS or Build
Server. Knowing the conceptual idea behind automatic deployments can help you if you
get any scenarios about it on the exam.

To achieve continuous deployment, you need automation of all possible parts of your deployment process. Automating the deployment process begins with automating the integration of the work that the developers do. Continuous integration (CI) is all about making sure
that your codebase stays healthy while developers make changes and check them in to source
control.
You first want to make sure that the code compiles. You do this by using a Build Server that
compiles the code whenever a developer checks in some new code. The Build Server of TFS
supports this. You can create continuous integration builds that execute whenever a check-in
finishes. If you have a lot of developers working on your project, you can switch your CI build
to a rolling build. This will roll several check-ins into one build to improve performance.
After that, you want to verify the quality of the code. You do this by first executing unit
tests, which are automated pieces of code that invoke some functionality in your system and
verify the outcome. This can include the price calculation algorithm for your online web shop,
the filter options for your search page, or another functionality that your application has.
Unit tests don’t have any external dependencies (such as a database or the file system). By
using dependency injection and mocking tools, you replace the external dependencies by inmemory objects during your unit tests. This ensures that your unit tests execute quickly and
that you can control the environment in which they run.

368

CHAPTER 5

Deploying web applications and services

MORE INFO  DEPENDENCY INJECTION AND MOCKING FOR UNIT TESTS

Unit testing is not part of the exam. In real-world projects, however, it’s a good practice
that leads to better code. For an introduction to the principles of dependency injection
and mocking, read the following MSDN magazine article: http://msdn.microsoft.com/en-us/

Unit tests can help you catch a lot of subtle bugs. However, they won’t find any errors that
occur only when working against real dependencies. This is where integration tests are used.
In your web shop, for example, an integration test would create a new order and then check
whether the data is correctly written to the database, the (test) payment provider is called,
and an email is sent to the user. These tests are slower, and normally there aren’t a lot of
them. But they are an important piece of continuous integration.
Microsoft supports the whole continuous integration and continuous deployment process with its Application Lifecycle Management (ALM) solution in the form of TFS. TFS is a
complete solution for managing your project, from code to bug tracking and change management. At BUILD 2011, Microsoft also announced a cloud-hosted version of TFS: Team
Foundation Service. Both these ALM tools can help you set up continuous deployment.
EXAM TIP

For the exam, it’s good to know that TFS is hosted on-premises on your own server. Team
Foundation Service is hosted in the cloud and is updated every three weeks.

When using Team Foundation Service, you can set up a continuous deployment process
when you host your website or services in Windows Azure. You can do this from a TFS or Git
repository. You can also use other options, such as Github, Dropbox, or Bitbucket. If you look
at Figure 5-4, you see a screen shot of the Windows Azure Management Portal. As you can
see, you have an option available for setting up deployment from source control.
After selecting the location of your code, Windows Azure monitors your code repository
for changes. When you do a new check-in, your code is automatically deployed to Windows
Azure. Using the Management Portal, you can roll back deployments if something goes
wrong. This is a nice integrated process. You don’t have to make any manual changes to automatically deploy to Windows Azure.



Objective 5.1: Design a deployment strategy

CHAPTER 5

369

FIGURE 5-4  Configuring deployment from source control in Windows Azure

MORE INFO  CONTINUOUS DELIVERY TO WINDOWS AZURE

For a walkthrough on how to set up continuous delivery to Windows Azure using Team
Foundation Service, see http://www.windowsazure.com/en-us/develop/net/common-tasks/
publishing-with-tfs/.

Achieving the same level of automation can also be done from an on-premises version of
TFS. Your applications are built by the MSBuild command-line tool. This tool enables you to
create a Windows Azure package from your code. If you create a new cloud project, you can
run the following command from within your project folder to get a Windows Azure package:
MSBuild /target:Publish /p:PublishDir=\\myserver\drops\

370

CHAPTER 5

Deploying web applications and services

After testing this command on your Build Server and making sure that everything works
correctly, you can now use this command to further automate your build.
You do this by editing the Build Definition files that TFS uses. These files contain a workflow that describes all the steps you want TFS to take to build your project. If you add the
Publish command to your workflow, your automatic build creates a Windows Azure package. You can use special Windows PowerShell commands to deploy the package to Windows
Azure as a part of your build.
MORE INFO  CONTINUOUS DELIVERY TO WINDOWS AZURE

For a walkthrough on how to set up continuous delivery to Windows Azure using an
on-premises TFS, see http://www.windowsazure.com/en-us/develop/net/common-tasks/
continuous-delivery/.

Deploying to web farms
When you expect a high load on your application, you need some way to make sure that
your application stays responsive. A simple way to achieve better performance is to buy
better hardware and increase the capacity of the server you are running your application
on. You can do this by adding more memory, a faster CPU, a solid-state drive (SSD), or other
better-quality hardware. This is called scale up. Especially with a database server, adding more
memory can give you a huge performance improvement. But scale up has its limitations.
Specialized server hardware can be expensive, especially when you also need a backup server
in case your main one fails.
Instead of scaling up, you can also scale out. This means that you use multiple servers
that all work together to host your website or service. Those servers can all be composed of
commodity hardware, and together they form what’s called a distributed environment or web
farm. Of course, there are other costs that come into play when scaling out. You will need
more licenses for software and more space in your server racks, and you will probably have a
higher power consumption.
EXAM TIP

It’s important to know the difference between scaling up and scaling out for the exam.
Make sure that you understand the advantages and disadvantages of both solutions.

This is why cloud solutions such as Windows Azure are so attractive. Instead of buying and
maintaining all those servers yourself, you just pay for the capacity you need on a pay-as-you
go basis. If your workload differs throughout the day, month, or even year, you can use the
elastic capabilities of Windows Azure to add or remove servers from your web farm. Now
that Windows Azure has shifted to a model in which you are billed for the minutes you use a
service, this can save you a lot of money.



Objective 5.1: Design a deployment strategy

CHAPTER 5

371

A web farm uses some kind of load balancer. It can be a software implementation, such as
Windows Network Load Balancing, or some dedicated hardware. The load balancer is responsible for distributing the requests across all your servers and making sure that they are used
in the most efficient way. By having multiple servers, you can increase the reliability of your
application. When a server fails for any reason, the load balancer detects this and won’t send
any requests to this failed server anymore.
The exam objectives state that you should know how to design a deployment strategy for
a web farm because deploying an application to a web farm does require extra work.
Normally, you need to configure only one server. Now you need to create the IIS applications and application pools on each server and make sure that they are configured exactly
the same everywhere (this includes encryption certificates, optional components, and other
extensions to IIS). When you use Windows Azure, a lot of those steps are automatically taken
care of.
One other thing you need to take care of is the way you deal with session state. In ASP.NET
and WCF, you can use a unique per-user session store to store data between requests. Normally, this data is stored in the memory of your server. When using a web farm, subsequent
user requests can be handled by different servers; this leads to problems when the session
data is stored in memory. To resolve this, you need to move the session state out of process to an external machine or even a database. That way, the session data of a user can be
accessed by all servers in your web farm. For the exam, it’s important to know the different
session states:
■■
■■

InProc is the default setting that stores the session data in memory on the server.
StateServer stores the session data in a separate process called the ASP.NET state
service.

■■

SQLServer mode stores session state in a SQL Server database.

■■

Off mode disables session state.

You can also choose to activate session affinity, meaning that the user requests will be
handled by the same server during the user’s session. However, not all load balancers support
this.
Instead of using session state, you can also use other techniques, such as storing data in
the query string or in the HTML that you send to the client. Of course, this can’t be used when
your data is sensitive, and it shouldn’t be allowed to be seen or modified by the user.
MORE INFO  CONFIGURING SESSION-STATE MODES

For more information on how to configure the different session-state modes, see http://
msdn.microsoft.com/en-us/library/ms178586.aspx.

372

CHAPTER 5

Deploying web applications and services

Thought experiment 
Choosing a deployment strategy
In this thought experiment, apply what you’ve learned about this objective. You can
find answers to these questions in the “Answers” section at the end of this chapter.
You are considering a deployment strategy for a web service that will be the back
end of a new app you will deploy worldwide on multiple platforms. Because of your
requirements, you will use WCF to create your back end. You are planning to build
your app in successive iterations that will expand the functionality. You also expect
that your user load will increase when your app gains popularity.
With this in mind, answer the following questions:

1. How can Windows Azure help you with the hosting of your back end?
2. Why should you plan for continuous deployment?

Objective summary
■■

■■

■■

■■

An XCopy deployment refers to a simple deployment in which you copy all the files
necessary for your website or service to the server.
When the deployment of your application becomes more complex, you can use the
Web Deployment Framework for your deployment needs.
Being able to continuously deploy your application is becoming more and more
important. TFS, Team Foundation Service, and Windows Azure offer a nice end-to-end
solution for automating your deployment.
A web farm can be used when you want to increase the performance and reliability
of your application. A web farm uses extra servers (scaling out) to serve requests. You
need to prepare your application to be able to run it on a web farm.

Objective review
Answer the following questions to test your knowledge of the information in this objective.
You can find the answers to these questions and explanations of why each answer choice is
correct or incorrect in the “Answers” section at the end of this chapter.
1. You need to deploy an application that requires some changes to the registry. Which

deployment strategy do you use?
A. Copy the website.
B. FTP client.
C. Web Deploy.
D. A web farm.


Objective 5.1: Design a deployment strategy

CHAPTER 5

373