Publishing to Windows Azure can be an excruciatingly long process.  It is especially frustrating if you make a small mistake that requires a second update just after the previous one.  I trust that this process will improve over time, after all, there’s really no need to generate a brand new set of VMs every time you want to make a small update to a project.  But until we have something more manageable, I thought I’d document my process for my team and other folks who might find it useful.

The steps below assume that you already have a deployment in place and that you’ve setup the appropriate certificates on your dev machine and in the Azure portal.  This also assumes that you’ve thoroughly tested your code locally and under a separate Azure deployment.

1. Build – In Visual Studio, change the Configuration to Production and Build the Solution.  See my notes below: Single Config File – Multiple Deployments.  This process will change the config files for production (modifying things like connection strings for production databases in your web.config files).
2. Publish – In Solution Explorer, right-click the Azure project.  Then click Publish.
3. Wait – The Azure roles will be packaged, uploaded, and installed on Windows Azure.  This can take 10 to 20 minutes to complete.  Generally, the rule is, the more you are in a hurry, the longer it will take.
4. Reset Configuration – Once the package is published, set the configuration back to the development setting.
5. Login –  Login to the Azure Portal.
6. Verify – Verify that the staging instance works.  I access the staging url for my web role and make sure there aren’t any errors.
7. Swap – Click on the Staging Deployment and then click Swap VIP to swap the IP Addresses of Staging and Production.  This process is very important; it ensures that my IP address doesn’t change during the update.
8. If you find anything wrong with your new code, you can quickly swap production and staging again to revert the code.
9. Delete – Once your new code is in production and you’ve verified that everything is working properly, stop and delete staging.  I do this to save on compute hours.  You should have a separate deployment for a true staging environment.  The Azure staging area should only be used as a quick “smoke test” before a move to production, and as a fallback if the production move fails.
10. Configure – If needed, modify the Azure configuration files using the Configure button.  For my application, I placed an item in the configuration file that allows me to control when my worker roles begin processing data.  In my file, I manually change the “active” setting to “true”.  This triggers my worker roles to begin processing normally.
11. That’s It.

 

Single Config File – Multiple Deployments

For non-Azure projects, I normally use the xcopy deployment approach, so it’s never been a problem for me to keep configuration and code changes separate.  With Azure, however, the config files are copied as part of the deployment and its easier to manage the different configuration settings in Visual Studio than at the deployment site.  I reviewed many different ways to handle this issue and the simplest approach that I found was the one discussed by Matt Berseth.

http://mattberseth.com/blog/2007/05/single_config_file_multiple_de.html

I changed the approach slightly to meet my needs.  First, I created a “configs” project that includes fandr.exe and the config.ini file.  I also created a batch file that performs the conversion for each project.  You can see the sample line that goes in the pre-build event for each project.  This process requires me to have a config template in each project.  I copy the existing config file and rename it to the same name with an underscore at the beginning (web.config becomes _web.config).  Then, whenever I change configurations and build the project, the template will be copied to the config file with the correct replacement values.

 

Example Pre-Build Event Command Line:

"$(SolutionDir)configs\config.bat"  "$(SolutionDir)" "$(ProjectDir)" $(ConfigurationName) web.config

 

Config.bat

@echo off

rem %~1 = SolutionDir
rem %~2 = ProjectDir
rem %~3 = Configuration Name
rem %~4 = Config File Name

rem Pre-build event example
rem "$(SolutionDir)config.bat"  "$(SolutionDir)" "$(ProjectDir)" $(ConfigurationName) app.config
rem

rem Skip if Same Configuration Name.
if exist "%~2%~3.curr.config" goto END

echo Config Name Changed.

rem del old Configuration Name files, create new one.
del "%~2*.curr.config"
echo > "%~2%~3.curr.config"

rem Skip if fandr.exe is missing.
if not exist "%~1configs\fandr.exe" goto END

echo Updating %~4.

rem Excute the update.
"%~1configs\fandr.exe" "%~1configs\config.ini" %~3 "%~2_%~4" "%~2%~4"

:END
echo Done.

 

I would love to simplify this process. I don’t see any reason why I couldn’t perform an xcopy update for my web roles. However, until I get around to doing something like that or until Microsoft creates a new process, it’s easy to follow this standard set of steps.