I'm using Azure Mobile Services for my mobile app backend. I'd like to make a copy of my current service (scripts, api, schedulers, tables etc.) for Test and Production environments. Is there an automated/scripted process to achieve this?
Unfortunately, at this point the answer is no. You have to create a new Mobile Service, recreate all the tables using the cli or web portal, copy over the database schema, copy over the scripts, and reconfigure any schedulers.
Once you have done that it's easier to maintain the workflow from dev->staging->production if you use a db schema tool like Flyway or Visual Studio. Also connect the git repos for the different services so that you can pull from dev and push to staging and then production.
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 a software vendor with a .net web solution that I want customers to be able to easily install / deploy into Azure Web Web Apps / Azure Websites along with a Sql Azure backend. I can't find any installer tool that supports this scenario. I have also looked into the Azure Marketplace but it seems the only option there is to create VM images. I want my customer's to avoid having to deploy to an manage VMs and adopt the IaaS model. Instead they should be able to install to Azure Web Apps with a package that copies all the web solution files and installs and connects the Azure Sql. Is this possible or will I have to manually deploy and configure Azure solution for each customer?
You can use the VS Marketplace to do the deployment. What you need is to create an ARM template. There is a huge number of samples here: https://github.com/Azure/azure-quickstart-templates - you can pick one of the web app ones - for example: https://azure.microsoft.com/en-us/resources/templates/201-web-app-sql-database/ - has a SQL database linked to a web app.
The ARM template allows you to do a "no-hands" deployment of the resources and know when they are ready for further action. You can also deploy from any of the supported continuous deployment options (see the template with a GitHub connection as an example) or you can use ftp/msdeploy after the deployment is successful.
This is a good tutorial https://learn.microsoft.com/en-us/azure/azure-resource-manager/vs-azure-tools-resource-groups-deployment-projects-create-deploy
This is the github example mentioned in previous answer
https://github.com/Azure/azure-quickstart-templates/tree/master/201-web-app-github-deploy
I would like use a continuous integration system in my projects. However, I don't want to use a server sitting in my office, instead I'd like my continuous integration server to run on Windows Azure. Has anyone set this up? Are there recipes to host Hudson or CruiseControl.Net (or any other CI system) within Azure?
We use the Build Manager in Team Foundation Server to push our automated builds to Azure. We set up our Azure hosted services to allow for Web Publish through remote desktop using this plugin - http://dunnry.com/blog/2010/12/20/UsingWebDeployWithWindowsAzure.aspx
You do not need to involve Team Foundation Server to use the plugin - you can set up your instances to publish to azure instantaneously through Visual Studio Web Publish without CI.
I think there are two parts to the Azure CI solution - automated builds from your source control and actually pushing the bits to azure. The plugin makes the publish to Azure much, much faster. So if you want real time access to changes on Azure, you will need to look into the plugin.
It sounds like you are trying to use Azure as an infrastructure provider, which runs a VM where your builds happen.
This is not a particularly good use-case for Azure. Azure is a platform to run your custom-built applications. While it does provide VM's similarly to Amazon or other IaaS cloud providers, those VM's are "stateless", can go up and down at will and meant to act as application servers where more than one can be up at any given time.
You can probably get this to work on an Azure VM but I am not sure if the pain would be worth it.
Azure's instances are application servers, not "windows servers".
HTH
I have installed Jenkins on Windows Azure, it works very well for me.
http://blogs.msdn.com/b/gongcheng/archive/2013/02/27/jenkins-on-windows-azure-the-missing-manual.aspx