Chapter 12. Preparing an Azure System for Production

In this last chapter, we're going to look at deploying our system to various environments for different stages of its life cycle. We'll explore the options for system configuration and create deployment packages manually on the Visual Studio Online Team Foundation build server. We'll finish this chapter by looking at monitoring and maintaining our Azure systems once they are live.

Project configurations for multiple environments

Until now, we've been publishing websites and cloud services straight from Visual Studio and using Entity Framework Code First Migrations to build our databases. Deploying systems to non-development environments from builds on a developer machine is not a good practice as we don't have a controlled way of producing a reproducible, versioned deployment. If we deploy a local build, there is no guarantee that there are no differences between the source control and the local copy of code; even if we build from a fresh branch, so that we think the code is clean and it builds on our development environment, there is no guarantee that it will run on a server as we may have developer SDKs installed, assemblies in the Global Assembly Cache (GAC) registry modifications, and so on.

Using a build server is a good way of making sure we have a clean build directly from a source control that is not influenced by the development environment and can repeatedly...

Building website deployment packages

Websites can be packaged into ZIP files and deployed to remote servers using MSDeploy; these packages can be used by system administrators or developers to deploy websites to the appropriate environment for testing or a live roll-out.

Manually publishing websites to the filesystem

We can manually build packages in Visual Studio, which, as I've said, is probably not a good idea for deployment packages (even if you're a lone developer with a limited budget, you can use the Visual Studio Online TFS build server, which gives you 60 minutes per month build time for free); however, it can actually be really useful to check that all the website content such as HTML pages, stylesheets, and scripts have been included, and that Web.config transforms have worked.

We'll look at manually creating a package in the following procedure:

1. Right-click on a web project and select Publish.

2. Click on the Custom button, and then enter a name in the New Custom Profile dialog (I've...

Building cloud service deployment packages

When we publish a cloud service to Azure through Visual Studio, we're creating a cloud service package (.cspkg) with an accompanying cloud service config (.cscfg—the same as in our solution) that is automatically deployed to Azure for us. We can create packages manually in Visual Studio or on a build server in a similar way to websites. This allows us to publish cloud services outside of Visual Studio from the portal or by using PowerShell.

Building cloud service deployment packages manually

As with manually publishing websites, it's not the best idea to publish cloud services built on a developer machine for the same reasons, but it can be a useful way of testing if our packages work as expected with the correct cloud configuration and application configuration transforms. We'll manually create a cloud package from Visual Studio in the following procedure:

1. Right-click on the cloud service project (not the role project) and select Package.

2. Select values...

Deploying web packages to Azure

Now that we've got a package built on the build server, we'll deploy it to Azure using the following procedure:

1. Create a website in the portal for one of the environments; I've called mine http://azurebakery-test.azurewebsites.net/.

2. Download the publish profile from the website's dashboard, and open it in Visual Studio (you can press Ctrl + E, D to quickly format it).

3. Unzip the drop package (make sure you unblock it first from the file properties) and copy the MyWebsite_Package folder to a temporary folder to make it easier to deploy.

4. Locate the following parameter in the MyWebsite.SetParameters.xml file:

   <setParameter name="IIS Web Application Name" value="Default Web Site/CustomerWebsite_deploy" />

5. Change the value to the name of the website created in the portal, like this:

   <setParameter name="IIS Web Application Name" value="azurebakery-test" />

6. Open a Visual Studio command prompt and change the directory to the MyWebsite_Package location (use cd\...

Deploying cloud packages to Azure

Cloud packages can either be uploaded to a cloud service in the portal or published using PowerShell; what you choose comes down to personal preference, although using PowerShell allows us to automate deployments. There is a great reference for deploying cloud packages using PowerShell at http://azure.microsoft.com/en-us/documentation/articles/cloud-services-dotnet-continuous-delivery.

Uploading packages into a service through the portal is really straightforward; we'll see how in the following procedure:

1. Nearly every tab in the cloud services toolbar has an UPLOAD button that is used to upload packages to instances with no current package, or an UPDATE button for instances with a current package loaded, so click on any one button on the toolbar for the instance you want to update:

   

2. Enter a DEPLOYMENT LABEL value, which helps you to identify the deployment, and browse to the .cspkg package and the .cscfg configuration, which we built on the build server. The...

Creating database scripts from Entity Framework Code First Migrations

We can easily create a T-SQL script from a database built with Code First Migrations by entering the following command in the Package Manager console:

Update-Database -Script -SourceMigration:$InitialDatabase

This command creates a T-SQL script for all migrations and opens it in Visual Studio. Unfortunately, scripts aren't created for the database seeding as this isn't part of Entity Framework migrations, so this has to be scripted separately.

Once we have these scripts, system administrators or database administrators can easily use them to build databases for our application environments without Code First Migrations. Once deployed, we can create more scripts to move to the next migration.

Of course, we can always manually create database schema scripts from SQL Server Management Studio. We can also use third-party tools such as Red Gate's SQL Compare product (http://www.red-gate.com/products/sql-development/sql-compare...

The go-live checklist

This is a list of quick checks to perform when we're putting a system live to make sure we've not missed anything:

• The website and cloud service Web.config and app.config have correct connection strings, API keys, and so on, for publish

• Cloud service configs have correct connection strings, API keys, and so on, for publish

• The website and cloud services have config settings overridden in the portal if required

• Logging level has been set to Verbose initially (particularly for new systems and major changes) to quickly diagnose any problems, and changed to Error once the system is stable to save on the storage space

• The website and cloud services have the starting instance count configured correctly, and auto-scale has been set up

• Databases have the correct max size configured

• A database backup strategy has been implemented

• Databases have been updated with the latest migration scripts

Monitoring live services

Once we have systems live on Azure, we need to monitor their health so that if a system is failing, we are aware of it and can start fixing it as quickly as possible. There are a number of tools within Azure that we can use to help us monitor our service, and we'll take a look at these in this section.

The Microsoft Azure portal

The main dashboard in the portal is a great way of getting an overview of all the services (you may need to page through them) as we get a simple visual indicator for each service that shows us its state. The new preview portal also has a nice world map that shows the status of all the data centers. If there is a problem with a service, we can quickly navigate to it and get more information from its own dashboard, and then start diagnosing the issue.

Checking the portal is a good activity to perform daily in order to ensure the general health of the services, and for system administrators this can be added to their existing daily checks.

The...

Azure daily service checks

This is a list of daily checks we should make for the Azure Bakery system once it is live:

• Check the portal dashboard for any service issues.

• Check error logs.

• Check the Service Bus queue and topic dead-letter queues (you will need to write a tool to do this).

• Check the Management Services Operational Logs for any live Azure issues that may affect services. You can also visit http://azure.microsoft.com/en-us/status/.

Azure periodic service activities

These are activities that should be performed periodically to ensure the health of the system:

• Check the individual monitoring dashboards for any high or unusual metric patterns so that any performance issues can be addressed.

• Check whether the database has sufficient capacity so that storage can be adjusted if required.

• Rebuild database table indexes (this could be done on a scheduled task as there is no SQL agent in SQL Azure). SQL Azure Databases, by default, are set to automatically recompute statistics, so this is not required.

• Archive and prune data that may no longer be needed to save on storage costs.

• Check whether the mobile service push notifications are receiving all broadcast notifications, and user-specific notifications are received by a test user.

• Touch-test application UIs to make sure there are no visual issues and everything is working as expected; problems may occur if there is an issue with some backend web services or storage.

• Evaluate service...

Azure tool list

We've already used a large number of tools in this book, and there are a lot we haven't looked at, so here is a list of useful tools for development and maintenance activities:

• The Azure portal: This is the main port-of-call for most Azure-related activities (https://manage.windowsazure.com and https://portal.azure.com).

• Visual Studio: Visual Studio, with the Azure SDK, is the most powerful Azure development tool on the market, and we've already seen what it can do for us in this book (http://www.visualstudio.com/).

• SQL Server Management Studio: We've had a quick look at this, but not used it to its full capabilities with Azure. It's a really useful tool for administrative and maintenance tasks on SQL Azure Databases (https://www.microsoft.com/en-us/server-cloud/products/sql-server/).

• Azure PowerShell: This is an additional PowerShell module, an extremely powerful tool for administering Azure systems, and it is also useful for developers when the portal or Visual Studio doesn...

Summary

This is the end of this book; I hope you've enjoyed reading it as much as I've enjoyed writing it! Make sure you download the code samples as they have everything we've covered in this book and all the extra stuff I couldn't fit in.

This is by no means the end of learning about Microsoft Azure. The entire software industry moves at a rapid pace, and as developers and IT professionals, we have to work hard to keep up-to-date with what's going on. Azure is evolving and growing all the time; we've barely scratched the surface of what it can do now, and have more to learn as time goes on. In the 5 months it has taken to write this book, mobile services' .NET backend has become generally available, a whole new SQL Azure service model has been introduced, and a new preview portal was released, to name a few things, so we need to run fast to keep up!

Questions

1. Why is it important to use a build server to build deployment packages?

2. How can settings be set at publish time for web packages?

3. Why is it not a good idea to put certain connection strings and API keys in configs and transforms source control?

4. What issues do we have with config transforms in cloud services?

5. Why could it be helpful to deploy a website to the filesystem or publish a cloud service package locally?

6. What problem may we face while trying to build projects rather than solutions on the Visual Studio Online Team Foundation build server?

7. What extra step do we need to perform when building cloud service packages on the build server?

8. When we run a deploy.cmd script, what is the difference between the /T and /Y arguments?

9. What approach should we take to set logging levels when deploying a new system?

Answers

1. It ensures that packages are built from clean code straight from sources control without contamination from the development environment.

2. When web packages are built on the build server, a ZIP package is created with a set of accompanying scripts, including SetParameters.xml, which contains settings that can be configured before deployment.

3. It is a security risk because anyone with access to source control can obtain details of production systems, which can be misused.

4. Cloud services don't support transforms by default, so we have to manually add config transform files and edit the project to achieve this; alternatively, we can use the Slow Cheetah tool.

5. It can help us check whether all the required files are included and that config transforms have worked.

6. The build server restores NuGet packages before building solutions but not projects, which means if we haven't checked in our NuGet package binaries (which we shouldn't), the build will fail.

7. We need to set the Output location setting...