IN THIS CHAPTER:
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.
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.
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:
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.
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:
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.
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.
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!
NOTE The file named index.html takes precedence over one named hostingstart.html in the same directory because of the default configuration in Windows Azure Web Sites. For more information on how to control the default document, please see Chapter 7, “Scaling, Configuring and Monitoring Your 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:
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.
Browse back to your site address and have a look around. Welcome to the cloud!
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.
Here's how simple it is to take the same site you used in the previous FTP example and publish it using WebMatrix:
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.”
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.
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.
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.
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!
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:
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.”
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.
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:
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.
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.
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.
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.