Chapter 2

Moving an Application to the Cloud

IN THIS CHAPTER:

• An overview of publishing options when moving a website to Windows Azure
• Setting and reviewing credentials and server hostnames
• Selecting the best deployment strategy

WROX.COM CODE DOWNLOADS FOR THIS CHAPTER

Please note that all the code examples in this chapter are available as a part of this chapter’s code download on the book’s website at www.wrox.com on the Download Code tab. You’ll be publishing all the related code from two of the projects in the download:

Basic Site Publish Files — This is a pre-baked deployment ready to push to the cloud, based off of the SimpleSite solution output.

SimpleSite — This is a Visual Studio 2012 solution that you will use as a publishing exercise.

Many friends of mine enjoy freely cracking open their computers and upgrading parts between coding sessions, but I would argue that there is a difference between being a software developer and a computer hardware technician. Sure, the roles are often blurred — anyone in my programming circles is more apt to diagnose a driver issue than most other professionals I know — but building and deploying new servers is outside our area of expertise.

I’ve spent my fair share of time in the server room; but as someone who truly loves the art of software development, I’d have to afford the reader that, for me, “compiler” is a preferred tool over “Phillips 2.” And when my intentions are to use an evening of my free time to pick up some new library or utility, or otherwise sharpen my coding skills, I don’t want to carry the burden of server maintenance at the same time.

Therefore, while I do tend to remain as far as possible from the rack and chassis these days, I have found great pleasure in adopting Windows Azure as my new favorite web server administrator. It takes only a moment to cut a new project with all the bits you need to deploy, monitor, and scale your site already in place. Windows Azure provides a fully upgraded environment with service packs applied — in moments — with just a few button clicks. Recent improvements in deployment scheduling also mean that Azure supports the latest .NET builds within days or weeks of general availability.

All of this is to say that you get quite a few personal benefits when using Azure in your deployment pipeline — not to mention potential corporate benefits — and you’re here now, looking to push your app up to the sky, so let’s get started! The deployment examples in this chapter make use of a trivial application that simply shows contact information for 25 random, fictitious people. These exercises don’t require any advanced configuration or any database connectivity.

In Chapter 8, “Deploying and Configuring Cloud Application,” you’ll have a look at a more complete example that allows you to explore the features covered in this and the other chapters.

UPLOADING YOUR WEB SITE VIA FTP

Long before users were bestowed OS-integrated FTP support, web application developers were making use of the command-line version of FTP to synchronize the server with our latest output. In fact, FTP likely predates most of today’s web developers themselves! With roots dating back over four decades, the protocol has been used in many different and varied scenarios and still provides much usefulness in today’s modern networks.

Gathering the Basics

There are only three prerequisites for publishing via FTP: knowing the name of the FTP deployment server to which you’re connecting, the subdomain name for the Web Site, and your username and password.

Provided you’ve configured your publishing credentials, setting up to leverage FTP is fairly straightforward. For the purpose of this example, you’ll work from the pre-baked version of a website that is ready to deploy, after an initial push with a single “hello world” sample.

There are a couple of details you should note at this point. The URL for the FTP Deployment server is located under the quick glance sidebar in the Dashboard of your website as shown in Figure 2-1. Your hostname will take on a format similar to the following:

FIGURE 2-1

ftp://waws-prod-blu-001.ftp.azurewebsites.windows.net

Also located in the quick glance side bar is the name of your deployment/FTP user. You may find that all server endpoints across your subscription are identical, but the user you log in with sorts out the home directory for each particular FTP session. Your username is in the format sitenameuser, where user is the name you specified when you created your publishing credentials. If you don’t recall what they are, you can reset them by following the steps in the section titled “Setting Your Deployment Credentials” in Chapter 1.

Connecting to the Server

Those of you who have previously worked with FTP may have a more elegant software package than working from Windows Explorer to connect and manage your files. You can perform the steps here in your preferred FTP client if you choose, or you can use the operating system’s built-in support for FTP. The latter approach, which is generally the more cumbersome choice, is what you’ll use for the purpose of this exercise, but feel free to follow along in whichever software you ultimately decide to use.

To make it easy to get started, follow these steps:

1. Copy your FTP hostname from your site’s dashboard to the clipboard.

2. Open a copy of Windows Explorer (press the Start key+E) and paste the hostname into the address bar. When you press Enter, Windows will try to connect to the server, at which point you’ll see the dialog shown in Figure 2-2.

FIGURE 2-2

3. Fill in your credentials and click the Log On option to complete the connection. After you are logged in, you will see the two folders that are created for you each time you provision a Web Site — namely, LogFiles and site.

4. Navigate into the site folder, and finally into the wwwroot folder, where you’ll find a single file called hostingstart.html. This is the directory you’ll target when you deploy the application.

---

NOTE

A heads up on security: Although FTP is provided as a convenience, it may not meet the security requirements of your organization. Remember that FTP sends your credentials via clear text — that’s right, no encryption — so anyone who might be “listening” to the traffic on your connection could exploit your username and password. For this reason, Azure provides a secure FTP (sFTP) endpoint for users who elect to use this as part of their workflow.

---

Keep this FTP directory open because you’re going to come back to it in just a moment.

Validating a Connection

Your sample Windows Azure Web Site is already live at this point and a default document is prepped and waiting for visitors to view. You can see this by opening your browser and navigating to the website, which uses the following naming convention:

http://your-app-name.azurewebsites.net

Therefore, for an application named “MovieNight,” the address is simply as follows:

http://movienight.azurewebsites.net

You should see a page similar to Figure 2-3 confirming that your application is running on WAWS.

FIGURE 2-3

You can change what users see when they arrive at your site by adding a new page to this directory. This section doesn’t get too fancy here — it just sticks with the bare bones to demonstrate the process:

   </html>
     <body>
       <p>Hello, cloud!</p>
     </body>
   </html>

Congratulations, you should now see your lovely handiwork!

Publishing the “Real” Site

Okay, so all you’ve really done here is push a text file, proving that the basic HTML skills are still in check. Now you want to see a true site — something beyond brochureware — live and kicking from that remote box. Nonetheless, you have picked up the basics of publishing via FTP through Windows Explorer:

• Connecting to the FTP server
• Locating your website directory
• Copying the files to the server

These are the same basic principles you will apply for subsequent pushes of your application. Let’s now put those principles in action and get some real content up there.

The code sample download contains a directory titled Basic Site Publishing Files, and within it another directory called wwwroot. You want to copy and paste all those files into the FTP directory, which results in a folder resembling the output denoted in Figure 2-4.

FIGURE 2-4

Browse back to your site address and have a look around. Welcome to the cloud!

PUBLISHING FROM WEBMATRIX

Microsoft WebMatrix provides a seamless development and deployment experience with built-in support for your Microsoft Account credentials. This means that it is aware of your Azure account and the Web Sites that you have provisioned, and has the ability to create and stage new websites for you. It’s not a traditional tool in a .NET developer’s toolkit, but it does have deep integration, support for open-source projects, an active community of developers who are building extensions, and an overall pleasant experience to experiment with.

To follow along with this section you must download the sample code for the book, which contains the files required to publish via WebMatrix.

Deploying Your Site for the First Time

Here’s how simple it is to take the same site you used in the previous FTP example and publish it using WebMatrix:

1. Open WebMatrix and log in using your Windows Azure credentials. The login link is in the top-right corner. If you have previously logged in, WebMatrix will remember your credentials.

2. Choose Open Folder from the welcome screen and select the folder containing the basic site publishing files. This is the wwwroot folder located in Basic Site Publishing Files, which is in your code download.

3. Click the Publish command in the Home ribbon. This will open the Publish Your Site dialog.

4. Select Create a New Site and fill in the required information. Azure needs you to name the site, choose a region, and associate the site with a new or existing database. You can create a new database if you like, but you won’t be using this resource for the purpose of this exercise. Figure 2-5 illustrates a completed example. Click OK to continue, and WebMatrix will download the related publishing profile for your site.

FIGURE 2-5

---

NOTE

The name of your Web Site is used to create a subdomain of azurewebsites.net. You might have noticed this in your site’s URL. For this reason, all Windows Azure Web Sites require a name that is unique among all the other sites hosted on Azure, and you will get an error message if enter a name that has already been selected. But don’t worry if your coveted name is no longer available as a subdomain; we’ll explore adding a custom domain name to your site in Chapter 7, “Scaling, Configuring, and Monitoring Your Site.”

---

5. Complete the test deployment by clicking Continue, and Continue again once the tests are complete. WebMatrix will ensure that the basic components of the site are compatible with the Azure Web Site and display the results. You are not required to do this step and can skip it if you like, but I recommend trying it out at least once to familiarize yourself with the process. This simple step can help catch deployment problems before they occur!

6. Review the Publish Preview screen. This contains the type of information that WebMatrix presents to you as you begin the publish process on each iteration. In future sessions you will usually see far fewer files; the initial deployment has to upload all the assets of the project, while subsequent deployments perform a differential upload, so only those files that have changed will be shown in the screen (and sent to the Web Site).

7. Click Continue to complete your deployment. The dialog will close and you’ll see a yellow alert panel at the bottom of the screen. This panel reports on progress as WebMatrix processes changes on your site.

When all files are in sync — the first deployment can take a few minutes — you’ll see the confirmation depicted in Figure 2-6 and you can click the link to view your site.

FIGURE 2-6

Publishing Changes to the Site

Now that the site is associated with a Windows Azure Web Site instance, changes that you make can easily be identified, and synchronizing the site goes more quickly. Try it out by following these steps:

   <h2>Index</h2>

That’s the basics! You can now refresh your site and see any changes you’ve made.

PUBLISHING THROUGH DROPBOX

Dropbox is a cloud-based file storage system that makes it easy to move files around from computers, tablets, phones, and through the web interface. It started with a private beta and grew to millions of users, and its creators recently announced that Dropbox users were uploading more than one billion files per day. So, yeah...they’re popular. Chances are good you already have a Dropbox account; if not, it’s easy to set one up. This section describes an easy way to move project files to a cloud application server.

Before you get started, please ensure that you have a Dropbox account set up and that you have downloaded the appropriate software for your operating system. Dropbox users will already be familiar with the client software that you use to keep your files in sync with your cloud storage account.

To follow along with this section you must download the sample code for the book, which contains the files required to publish via Dropbox.

Associating Your Web Site with a Dropbox Folder

Because Dropbox is not a Microsoft product and doesn’t exist as part of the Windows Azure offering, you first need to set up a trust between the services. Start by creating a new site from your Azure portal as you did in “Creating a Simple Site” in Chapter 1, and then follow these steps:

When you are done you’ll see a confirmation similar to that in Figure 2-7, letting you know that everything completed successfully. You’re now published and online. Congrats!

FIGURE 2-7

Pushing Files to the Cloud through Dropbox

Dropbox integrates directly with your operating system so well that it’s hard to tell that it isn’t just another file location on your computer. In the preceding steps, Dropbox created a directory called Apps in the root of your Dropbox folder, and a folder for Azure nested within it. Inside Azure is yet another folder that bears the name of the folder you created earlier — by default, the name of your web site, which for this example would be “movienight.” Time to deploy your site:

1. Open Windows Explorer and locate the folder for your website by selecting Dropbox Apps Azure.

2. Open another Windows Explorer and locate the wwwroot folder inside of Simple Site Publishing Files from the code download for the book.

3. Copy all files from the wwwroot folder to your website folder in Dropbox. At this point I recommend getting yourself a drink! Otherwise, you can log into Dropbox and wait for all the files to show up. It takes a while to sync.

4. Navigate to your website’s dashboard in your Azure portal.

5. Click the Deployments tab, and then click the Sync button. It will take a moment to capture all the files, and the view of the deployments screen will change to show you your active deployment.

6. Return to your dashboard, and click on your site URL under the Quick Glance section.

If you make changes to your site in the Dropbox folder on your machine, all you have to do is hit that Sync button again and your site will be updated. Feel free to give it a try!

As you can see, this model whereby Windows Azure “pulls” your site from another location can be pretty powerful, and the sharp reader will be wondering about the list of deployments that is amended with each sync operation you perform. Hang tight, you’ll be working with deployments in depth in Chapter 3, “Managing Deployments via Source Control.”

GOING TO THE CLOUD WITH VISUAL STUDIO 2012

The last piece is one that I put in the game changer category. Publishing to Windows Azure through Visual Studio 2012 has all but eliminated any barriers for any experienced developer who wants to try running a website on the cloud. This could be the single most enticing feature that will draw you in and make you want to experiment with Windows Azure Web Sites, if you haven’t already done so.

Now that I’ve set the bar so unrealistically high that you are likely having a hard time believing it, I’m going to walk you through the steps and hopefully gain some face in the process!

To follow along with this section you must download the sample code for the book, which contains the files required to publish with Visual Studio 2012.

Downloading Your Publishing Profile

The key to this magic show is the publishing profile that is exposed on the dashboard of any Windows Azure Web Site. This is an XML file that gives Visual Studio the instructions it needs to complete a deployment to Azure. You can create your own XML file and add it to your project manually, but Windows Azure Web Sites and Visual Studio 2012 give you an easy alternative: Download the pre-configured settings and easily import them into your project.

Pop back into your portal and use Quick Create to add another site to your account, and then follow along with these steps:

Registering the Publishing Profile with Your Project

You don’t have to create the project from scratch, but you can if you like. For a head start, there is a solution entitled “SimpleSite” in the code download for the book. This is the source code for the files you’ve been deploying so far throughout this chapter. The following steps take you through the publishing process for the SimpleSite solution, but it’s an easy transition to use your own site in its place.

1. Locate and open the SimpleSite.sln solution file in Visual Studio 2012.

2. Select Build Publish from the menu. Visual Studio will launch the Publish Web dialog.

3. Switch to the Profile tab if you’re not already there, and click the button labeled Import next to the profile selection dropdown.

4. Navigate to and select the publishing profile you downloaded in the previous section. You’ll see all the credentials and connection information you need automatically filled in for you. You can click the Validate Connection button to assert that you have a valid configuration.

5. Click the Publish button. Visual Studio takes care of the heavy lifting for you.

From this point forward, all you have to do is click Build Publish to push updates to your site. And the real value of using this deployment mechanism? You can add multiple publishing profiles to your project and deploy on a whim to any of them.

The publishing profile is the same format that is used by Web Deploy and it can be incorporated into your physical servers as well, meaning you can deploy as easily to your test environment as you can to a scalable, cloud-based production server running on Windows Azure. You can even leverage these profiles as part of your continuous deployment process or otherwise in your build scripts.

SELECTING A DEPLOYMENT STRATEGY

It’s fairly trivial to work with tools like FTP and DropBox to deploy your site, both of which provide a method that is as straightforward as using the file system to copy files. WebMatrix and the Visual Studio IDE give you a method of publishing from directly within the tools you’re using to create your site. There can be great benefit from being able to directly push files to the cloud, but how do you keep track of changes? What happens when you work with other team members? Will you be expected to support multiple versions of your site?

These techniques let you play with the metal, so to speak, and grind files out quickly and effectively with the caveat that you’re unable to really take your deployments to the next level. It’s hard to work with other folks on your team without overwriting files and losing work, or worse, even rendering your site inoperable. There is no way to roll back to a previous version — or even track previous versions — and all of a sudden you start to realize that “quick” and “effective” might not be what you’re looking for.

Truthfully, publishing as illustrated in this chapter is quickly outgrown by the serious hobbyist and professionals alike. You’re going to need to take control of your source and start using repositories. If you’re working with other team members, on open source projects or even alone, using a source control repository really opens the door to some deployment methods that pair up really nicely with Windows Azure Web Sites. If you’re looking to build a strategy for deployment it should not include copying and pasting files, nor should it include any process which permanently overwrites previous work.

Unfortunately, all of the techniques demonstrated thus far allow you to fall into those traps. Fortunately, you’re about to learn how to tie your code base hosted in any one of several source control providers to the automated deployment facilities of Windows Azure. Chapter 3 will cover this ground and give you some solid footing as you move past these basic concepts and towards an environment that fits most development realities.

SUMMARY

There are almost as many ways to get your web application up on the cloud as there are ways to say “hello,” and you’re only halfway through them! You should now feel pretty comfortable using several different tools to deploy your site and keep it up to date.

Be it simple operations as basic as copying files for FTP or Dropbox, using more complete tooling and authoring environments such as WebMatrix, or building a solution in a fully featured IDE like Visual Studio, you’ve seen how the friction related to deployment has been significantly lessened. So it’s time to start experimenting!

Ultimately, chances are good that you’ll be working with more mature sites, sites built through the effort of a team, with a distributed group, or for clients that work offsite; and for those types of projects, you’ll likely need to leverage some kind of source control, the subject of the next chapter.