3 Comments

This is the second post in the Real World Problems with Windows Azure Web Sites. The first post summarized how one can manage multiple environments (development, staging, production, etc) using a Git repository with a branching strategy. Not everyone wants to use Git, and most would prefer to stay in their favorite IDE – Visual Studio 2012 – all day to do pretty much everything. My buddy Sayed Hashimi told me about Visual Studio profiles a few weeks ago and I’d been wanting to write up something on how it could work with Windows Azure Web Sites. This post follows up on the idea of managing multiple Windows Azure Web Sites, but rather than do it with Git, I’ll show you how to manage multiple sites with only Visual Studio’s awesome publishing-with-profiles features.

Set Up the Environments

The first step in the process is to have your multiple sites set up so that you have environmental isolation. In this case, I’m being thorough and requiring there are two gates prior to production release. All three of these sites are in the free zone, for this demonstration.

01-sites-provisioned

If this was fully realistic, the production zone would probably be at least shared or reserved, so that it had a domain name mapped to it. That’s the only site that would cost money, so the development and staging sites would have no impact on the cost I’ll incur for this setup.

Once the sites have been created I’ll go into each site’s dashboard to download the site’s publish settings profile. The publish settings files will be used from within Visual Studio to inform the IDE how to perform a web deploy up to my Windows Azure Web Site environment.

02-download-publish-profile

Once I’ve downloaded each of these files I’ll have them all lined up in my downloads folder. I’ll be using these files in a moment once I’ve got some code written for my web site.

SNAGHTMLbb9ed58

Now that I’ve got all my environments set up and have the publishing settings downloaded I can get down to business and write a little code.

Setting up the Web Application Project

I know I’ll have some environmental variances in the deployment details of this web application. I’ll want to use different databases for each environment, so I’ll need to have three different connection strings each site will have to be configured to use for data persistence. There’ll be application settings and details and stuff, so the first thing I’ll do in this simple ASP.NET MVC project is to prepare the different publishing profiles and the respective configuration for those environments.

To do this, I’ll just right-click my web project and select the Publish menu item. I’m not going to publish anything just yet, but this is the super-easiest way of getting to the appropriate dialog.

image

When the publishing dialog opens, I’ll click the Import button to grab the first environment’s publish settings files.

SNAGHTMLbc3d1f0

I’ll grab the first publish settings file I find in my downloads folder, for the site’s development environment.

SNAGHTMLbc4eff3

Once I click Open, the wizard will presume I’m done and advance to the next screen. I’ll click the Profile link in the navigation bar at this point one more time, to go back to the first step in the wizard.

If, at any point during this process you’re asked if you want to saved the profile, click yes.

SNAGHTMLbc7a83d

I’ll repeat the import process for the staging and production files. The idea here is, to get all of the publish settings files imported as separate profiles for the same Visual Studio web application project. Once I’ve imported all those files I’ll click the Manage Profiles button. The dialog below should open up, which will show me all of the profiles I’ve imported.

SNAGHTMLbcad50b

This part isn’t a requirement for you or a recommendation, but I don’t typically need the FTP profile so I’ll go through and delete all of the *FTP profiles that were imported. Again, not a requirement, just a preference, but once I’m done with it I’ll have all the web deploy profiles left in my dialog.

SNAGHTMLbcc102b

I’ll just click Close now that I’ve got the profiles set up. Now that the profiles are setup they’ll be visible under the Properties/PublishProfiles project node in Visual Studio. This folder is where the XML files containing publishing details are stored.

image

With the profile setup complete, I’m going to go ahead and set up the configuration specifics for each environment. By right-clicking on each *.pubxml file and selecting the Add Config Transform menu item, a separate *.config will be created in the project.

image

Each file represents the transformations I’ll want to do as I’m deploying the web site to the individual environment sites. Once I’ve added a configuration transformation for each profile, there’ll be a few nodes under the Web.config file I’ll have the opportunity of configuring specific details for each site.

image

Now that I’ve got the publish profiles and their respective configuration transformation files set up for each profile, I’ll write some code to make use of an application setting so I can check to make sure the per-profile deployment does what I think it’ll do.

Now, if you’re thinking to yourself this isn’t very practical, since I couldn’t allow my developers to have the ability of deploying to production and you’re compelled to blow off the rest of this post since you feel I’ve completely jumped the shark at this point, keep on reading. I bring it back down to Earth and even talk a little release-management process later on.

Environmental Configuration via Profiles

Now I’ll go into the Web.config file and add an appSetting to the file that will reflect the message I want users to see whenever they browse to the home page. This setting will be specific per environment, so I’ll use the transformation files in a moment to make sure each environment has its very own welcome message.

image

This is the message that would be displayed to a user if they were to hit the home page of the site. I need to add some code to my controller and view to display this message. It isn’t very exciting code, but I’ve posted it below for reference.

First, the controller code that reads from configuration and injects the message into the view.

image

Then I’ll add some code to the view to display the message in the browser.

image

When I browse the site I’ll get the obvious result, a simple hello message rendered from the configuration file on my local machine.

SNAGHTMLd3eb220

I’ll go into the development configuration profile file and make a few changes – I strip out the comments and stuff I don’t need, and then I add the message appSetting variable to the file and set the transformation to perform a replace when the publish happens. This basically replaces everything in the Web.config file with everything in the Web.MySite-Dev - Web Deploy.config file that has a xdt:Transform attribute set to Replace.

image

I do the same thing for the staging profile’s configuration file…

image

… and then for the production profile’s configuration file.

image

With the environmentally-specific configuration attributes set up in the profile transformations and the publish profiles set up, everything should work whenever I need to do a deployment to any of the environments. Speaking of which, let’s wrap this up with a few deployments to our new environments!

Deployment

The final step will be to deploy the code for the site into each environment to make sure the profile configuration is correct. This will be easy, since I’ve already imported all of my environments’ configuration files. I’ll deploy development first by right-clicking the project and again selecting the Publish context menu item. When the publish wizard opens up I need to select the development environment’s profile from the menu.

SNAGHTMLd55a0ea

Once the publish process completes the site will open up in my browser and I can see that the appropriate message is being displayed, indicating the configuration transformation occurred properly based on the publish profile I’d selected to deploy.

SNAGHTMLd572671

Next, I right-click the project and select Publish again, this time selecting the staging environment.

SNAGHTMLd585116

When the publish completes, the staging welcome message is displayed.

SNAGHTMLd59b886

If I repeat the same steps for production, the appropriate message is displayed there, too.

SNAGHTMLd5aeeb4

In a few short steps, I’m able to set up a series of environments and publish profiles, that work together to allow me separate deployment environments, with little extra work or overhead. Since the profiles are linked to the configuration transformations explicitly, it all just works when I deploy the site.

Release Management

As promised earlier in that blockquote up there, I want to stay with the “these are real world scenarios as much as possible based on my real-world experiences and questions I’ve been asked” mantra, I feel it’s necessary to get into the idea of release management insomuch as how it’d apply here. In the previous example I was using Git branches to gate releases. In this example, I’m not using any centralized build solution, but rather assuming there’s a source control environment in between the team members – developers, testers, release management, and so on – but that the whole team just chooses to use the Web Deploy awesomesauce built into Visual Studio.

Think of a company with aggressive timelines but who still take care to gate releases but choose not (for whatever reason) to set up a centralized build system. This company still feels strongly about managing the release process and about maintaining separate chains of testing and signoff responsibility as code is moved through the environments on the way to a production release, but they love using Visual Studio and Web Deploy to get things into the environments as quickly as possible. 

The diagram below demonstrates one potential release cycle that could make use of the publish profile method of gating deployments through a series of environmental gates.

deployment-strategy

Assume the team has come to a few conclusions and agreements on how their release cycle will execute.

  • All the team members are relatively technical and comfortable using Visual Studio with web application projects
  • The team uses a source control method to share source code and to distribute it internally between team members
  • The web application project checked into source control has with it the publish profile for deploying the site into the development Windows Azure Web Site
  • Testers maintain copies of the staging publish profile setting, are regarded as the owners of the staging environment, and are the only team members who can deploy code to the staging Windows Azure Web Site
  • Release managers maintain copies of the production publish settings files, are regarded as the owners of the production releases, and are the only team members who can deploy code to the production environment
  • As developers, testers, and RM’s complete their respective testing phases in the environments they own and are ready to sign off, they escalate the deployment process to the next level
  • Following escalation, the first general step is to test the previous environment for verification purposes, then to deploy to the next environment and to begin testing of the deployment in that environment

Luckily, this sort of situation is quite possible using publish profiles and free Windows Azure Web Sites used as environmental weigh stations on the way to be deployed to a production site that’s deployed to multiple large reserved instances (for instance).

Summary

The convenient partnership between web publishing and Windows Azure Web Sites shouldn’t be regarded as an indicator of it creating the potential for cowboy coding, but more considered a tool that when coupled with a responsible release cycle and effective deployment gating can streamline and simplify the entire SDLC when your business is web sites.

I hope this post has introduced you to a method of controlling your deployment environments, while also allowing you to do the whole thing from within Visual Studio. Later on, I’ll follow up this post with an example of doing this sort of thing using Team Foundation Services.

Hopefully, you have enough ammunition to get started with your very own Windows Azure Web Site account today, for free, and you feel confident you’ll be able to follow your very own release management process, without the process or architecture slowing you down. If you have any questions about this approach or the idea in general, feel free to use the comments form below.

Happy coding!

Comments

Comment by alastair

Hello,

Very informative. If I want to apply the transforms during a package operation rather than a publish, how could I do that? I am specifically interested in doing this for a WebRole rather than a website.

One option would be to have a publish profile and associated transform called, for example, AzureTest and set the publish profile to push the files to a known location such as "..\publish\Myfiles" then use the physicalDirectory attribute of the site element in the ServiceDefinition file to pick up the results of the publish operation. This would require the user to execute the publish operation first, followed by the package operation. The risk is that if they forget to do the publish prior to packaging, then they will either get a package failure. Worse, if there are files there from a previous attempt, they may package an old set.

Do you have a better suggestion?

alastair
Comment by Kelly

Brady,

Thank you for this article. Very recently (Jan, 2014) Microsoft released Staging Publishing Support for Windows Azure Web Sites. I'm trying to utilize that in a staging/production scenario, using the Azure Web Site "swap" button to swap staging and production sites. So, rather than publishing from VS to Staging, and then publishing from VS to Production, I'd like to be able to publish from VS to Staging, and if all is well, just use the "swap" button to get the Staging site into production.

The problem I'm having is that the site I've built uses two different sets of Web services, each running in their own Azure Web Sites, each of which also have Staging Publishing enabled.

When accessing the Staging site, I want it to use the Staging sets of services, and when the "swap" button is pressed, I want that site, which is now Production, to make requests to the production web services.

Do you have advice on how I can achieve this using the new Staging Publishing? An article on that would be very helpful.

Thank you for your posts!

Comment by russ

Hi there,

Great article but I have an issue.
Mostly it is outlined here:
http://stackoverflow.com/questions/24500203/web-config-transforms-not-working-with-visual-studio-online-vs2013-and-azure

Basically, I am using CI and visual studio online and I have tried everything but my configs don't transform on Azure.

Any ideas?

There are no errors I just keep getting the appSettings from the standard web.config.

thanks
Russ

Post comment