CODEWITHSUNDEEP
azureweb-applicationsdeployment
splattne
splattne

Reputation: 104050

Setup and Deployment of a Multi-Part Web Application in Azure

Note: I'm relatively inexperienced in Azure. So sorry if I'm missing some obvious points or choices.

I need to evaluate how to set up and deploy (with frequent updates) three .NET web applications which are tightly coupled.

Here's a simplified diagram of the system’s parts. There are three web applications:

Architecture

The web applications are separated application but they share the same database and internally use the same domain logic and database libraries.

So, when there's a software update which sometimes automatically upgrades the database’s schema, it must be deployed at the same moment to all three web apps (within few seconds).

What's the best way to accomplish this on the Azure platform (App Services)?

Bonus Question

Currently, I’m running dozens of these systems (each consists of three applications). Is there a way to deploy the runtime files to a “Azure-local” place and distribute them afterwards first to group 1, then to group two etc.?

Instance Groups

Upvotes: 1

Views: 248

Answers (2)

Rob Reagan
Rob Reagan

Reputation: 7696

CSharpRocks's answer is great for Web Apps. For the database portion, I've got two suggestions:

1. Database Project/DACPAC

Deploy by publishing a Database Project. Under the covers, this deploys a DACPAC to your target database. This can be done via publishing from Visual Studio, publishing via a VSTS deployment task, and I believe it can also be done through Powershell. I have personally only read about deploying DACPACs via Powershell.

Given the scenario you describe, it sounds like you'd want to deploy your code changes to a staging slot for all Web Apps. Then you can deploy your Database Project, then use Powershell to slot swap.

The advantage of a Database Project is that you're guaranteed for your target database to match your Database Project's state. The downside is that if things go sideways, there's not a super-easy downgrade path.

2. EF Code First Migrations

A Code First Migration will allow you to specify upgrade and downgrade scripts for your database. I've only executed these through the package manager console, but they can also be executed from a standalone executable, allowing you to script their execution.

The benefits of Code First Migrations are that you can execute a scripted downgrade. This, coupled with a Web App slot swap going back to your previous application version gives you a little more assurance that you can roll back if things go south on you.

The other feature to point out is that EF Code First executes the changes that you script, and nothing more. Therefore the following interleaving of events is possible:

  1. Deploy a code first migration.
  2. Manually make a schema change in your DB
  3. Deploy a second code first migration.

EF Code First Migrations don't care at all about step #2 and will leave your manual changes. This is not the case with deploying a database project. The database project will ensure that your target database matches the Database Project definition.

There are some practical considerations at work here. If you're using a SQL Azure DB and are using automatic performance tuning, Azure will roll out/delete indexes as it sees fit. If you use a Database Project and do NOT include those automatic index updates, deploying a Database Project will roll those index changes back!

Upvotes: 1

user793891
user793891

Reputation:

Have you looked at deployment slots? You can automate the swapping of the 3 App services with Powershell or the Azure CLI and swap all 3 at the same time.

You can also automate the deployment of all systems from a repo to a staging slot and automate the swap with Powershell or the Azure CLI, one system at a time.

Upvotes: 1

Related Questions