I have a new ASP.NET MVC project that will be hosted in Azure using their Cloud Services with multiple web roles running. My question is about how to do production deployments using FluentMigrator to do the database changes.
If I run FluentMigrator during my TeamCity deployment it seems that it would update the database first and then would do deployments to the multiple web roles one at a time. Therefore, it seems that some users would be accessing the old version of the site and using the new database structure which will lead to mismatches and exceptions being thrown.
What are best practices/suggestions for doing deployments to a production Azure SQL Database environment using FluentMigrator?
First off, make sure you deploy to the staging slot and only do a VIP swap once you are happy everything is working fine.
If your migrations include things like adding columns, indexes and tables - these will be non-breaking changes and your old code should work just fine against the new database.
If your migrations include breaking changes though (changing column names, dropping columns, changing columns datatypes) then you should put up a holding page while you deploy.
We have a flag we set in the config file that serves a holding page while we are doing these type of deployments.
Related
I want to manage and maintain a single instance of Umbraco CMS locally and on the fly, when customers want a duplicate instance, be able to automatically create new instances of the application.
Ideally I'd like a process whereby it builds from the master branch, creates an azure app from the build and deploys it to a new Azure Web App, along with cloning a database on an existing Azure SQL Server. And if I have any updates that I want to push to all instances, I would like to build and deploy updates to all Azure Web Apps created so far.
It's basically a very vertical multi tenant application that requires new instances of it. There is no crossover other than they share the same code base and was cloned initially from the same database.
Are there any existing services that Azure provide for a single repo to multiple Azure Apps, and be able to continually deliver updates to all these clones?
Or is this more bespoke? I'm leaning to bespoke but I really want to check before reinventing the wheel.
This sounds a bit like the concept of Baselines that Umbraco Cloud provides... https://umbraco.com/umbraco-cloud-pricing/#baseline
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:
Backend
Frontend
API
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.?
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.
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:
Deploy a code first migration.
Manually make a schema change in your DB
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!
I have an existing App Service created in Azure, which has a connection string linking to the database, 'Easy Tables' configured, and a whole bunch of custom API methods and table definitions done via the 'App Service Editor'.
I'm at a stage in development where I need to use deployment slots, in order to have separate environments for development, test, and eventually live.
On creating a deployment slot, I have the option of 'Configuration Source' - where I can clone an existing application.
I select my existing app when I choose this option, however my Easy Tables or API configurations are not carried over with it, and it appears I need to set them up again?
Considering that I already do have everything set up in the App Service, how can I transfer the Easy Tables and API methods over to the new deployment slot without recreating each file one by one.
The end goal that I am trying to achieve is an exact duplication of my current web app - pointing to a separate database, having it's own collection of API calls and easy tables - all using the existing app as a starting point, with a URL different to the existing app.
however my Easy Tables or API configurations are not carried over with it, and it appears I need to set them up again?
Answer in short yes. According the Set up staging environments in Azure App Service, we could know the if we choose WebApp as Configuration Source, it copies the configuration info such connectionstring setting, appsetting etc. not the content of the WebApp.
There is no content after deployment slot creation. You can deploy to the slot from a different repository branch, or an altogether different repository. You can also change the slot's configuration. Use the publish profile or deployment credentials associated with the deployment slot for content updates. For example, you can publish to this slot with git.
I am using Microsoft Azure cloud Services, I am deploying my local code to production and staging.
I came across one scenario as below:
If production code is in running and some users are active to the application site, now I want to deploy my code without loosing active users (without taking my application down).
Output that i want: So my new code will be deployed and active users (Log in users) will be not affected.
How to solve it?
Just in case you have found an answer to this, the solution to this problem is to have multiple deployments (staging and production) and then swap them when you're ready to promote the staging to production.
https://azure.microsoft.com/en-us/documentation/articles/cloud-services-how-to-manage/#how-to-swap-deployments-to-promote-a-staged-deployment-to-production
Just getting used to VS2012 publishing of Cloud Services. At present I have a one instance webrole which contains a MVC3 application. I can publish it to Azure without issue, and it creates the Cloud Service>Web Role>VMs. Fine. Takes a little while.
However when I do a little code change how can I migrate just this code change without replacing all the VMs that implement the WebRole etc.
It seems that Code and infrastructure are inseparable, or have I misunderstood. Is there a way to just update the code bit?
Thanks.
When you roll out an update, you upload an entire package containing not only your code files, but also the configuration for the VM, such as # of instances, ports to open on the firewall, local resources to allocate, etc. These configuration settings are part of the code package - so there is more going on than just updating code files.
However, there are a couple of methods you can use to have more granular control over updates.
Use Web Deploy. One thing to keep in mind, is that any automatic service updates will restore your website to the last fully-deployed package, which may not be as up-to-date. You would only want to use this in staging, then do a full package update for production rollout.
Use an Azure Web Site instead, which allows continuous integration with your source control provider, and direct updates to the code.
Use an Iaas VM instead. These are basically the same as running your own custom server in the Azure cloud, and you have full control over the OS. However, you also have full responsibility for keeping the OS updated and secure.
You can also enable RDP to your Azure Web Role VM's. You will find all your code files there and IIS, but I wouldn't recommend updating your code this way for the same reasons listed in #1.
The code and infrastructure, in a cloud service, are actually separate. All you upload is a deployment package containing just your code and supporting libraries / files. You don't upload a vhd. Azure provides that for you, spinning up a vhd, and then accessing your code on a file folder on that vhd. Same process happens each time you scale out to more instances.
when you make a code change, you build a new deployment package and deploy that. If you do it as an in-place update (vs delete+redeploy), each role is updated on each instance (when you have multiple instances of a role, they're not all updated at the same time). You can even specify that you only want a single role within the deployment to be updated (helpful if, say, you have a worker role in addition to your web role, and want to leave all the worker role instances running).
when the code update happens, the VMs aren't replaced, but they are recycled, and when they start back up, they are running the updated code.
You can use WebDeploy with Cloud Services in production across multiple servers using the AzureWebFarm project (disclaimer: I maintain it).
Alternatively, you can also use the excellent Octopus Deploy deployment technology in conjunction with the AzureWebFarm.OctopusDeploy project (disclaimer: I maintain this one too).
To be honest though, if you just have a simple web app then I wouldn't both with cloud services - I'd just use Web Sites. Feel free to check out my blog post to see the situations which might force you to use cloud services though.
If you enable WebDeploy on the cloud service, you can use web deploy to publish the MVC application.
See http://msdn.microsoft.com/en-us/library/windowsazure/ff683672.aspx for details.
All of the above answers are correct and if you are trying to change your code for a production service you definitely want to do an in place upgrade as described. However, frequently during the dev/test phase or troubleshooting I want to make one small change and test it out quickly. To do this check out http://blogs.msdn.com/b/kwill/archive/2013/09/05/how-to-modify-a-running-azure-service.aspx which describes how to modify the code via RDP to the Azure VM.