We currently use a very traditional deployment methodology. Developers build EXE packages which are then handed to the operations team who install it onto VMs (one VM per customer). Our company is B2B and resources between customers is rarely shared.
Now, we are looking at using Azure App Services to deploy software.
I can deploy our app to Azure App Services, but what is the recommended way to deploy to many customers? The documentation online talks a lot about continuous deployment, so is the expectation that we maintain deployment profiles for each customer?
I would start with exploring the AZ-CLI to script creation of AppServices. Then use the AZ-CLI to deploy your apps to the different customer app services. With regards to the different customers: I would start with an AppService per customer within a single App Service Plan, in that way you can limit the costs for now.
We use Azure DevOps build and release pipelines for creating (and updating) App Services and also for building and deploying to these app services. Based on certain conditions we first deploy to Development, after approval gates to Test, QA and finally Production. Nowadays we use YAML pipelines for most tasks, but we started with Azure Portal and AZ-CLI. It takes time to evolve from manual deployment to fully automated.
Related
At the company that i work, they deploy applications to azure using Azure App Services.
This involves creating the App service manually, and setting up the pipelines manually.
My question is if there is another way to host and run applications in Azure without using App Services?
The reason for this is that i don't like the manually work when setting up a app service and all it's configuration.
Any suggestions?
What you actually need is setting up CI/CD pipelines for your application to create resource(AppService in this case) and deploy on them.
If you are new to Azure Devops, i would highly recommend to explore Devops starter service to deploy your application with few clicks and see how it creates resources and pipelines automatically
On the 2nd question, there are many compute options available on Azure such as Virtual Machines , AKS (Containers Orchestration) , Container instances etc.
You can explore those compute options using the decision tree here
I have been developing a React SPA with Python Api using Docker and Azure Web Apps for Containers.
Now when I want to develop the production deployment process I find that there are no app service tiers which include slots other than very expensive production tiers.
Am I mistaken?
If not, is there a reason for this?
You could see S1 or above price tier also support Staging slots when you expand See additional options tab.
I am trying to understand the relationship between VSTS and AZURE.
I am planning to deploy some apps in Azure and wanted to know if there is any way within Azure that we can maintain releases and builds? or do we have to use VSTS?
EDIT
I currently have everything in on-premise TFS and am using on-premise MS Release Management for managing my releases (which are a bit complicated).
Now Azure does offer continuous deployment using App Service integration but I feel that might be more apt for simpler applications with relatively simple release plans (Is this assumption correct?). Exploring Azure, I also see Octopus deploy (in the compute section). Does that mean that we can manage deployment inside of Azure without using VSTS? (I currently dont care about work items, backlogs and process inside of TFS)
Regarding the relationship between VSTS and Azure.
Want to authenticate users and control access with Azure AD Team Services: Access with Azure Active Directory (Azure AD)
Set up billing when you need more users, pipelines etc… Set up billing to pay for users, pipelines, and cloud-based load testing in Visual Studio Team Services
Regarding deploy apps to azure, there are many ways, for example:
Continuous Deployment to Azure App Service, the source code could be in VSTS, Git, Bitbucket etc…
VSTS build and release, the source code can be in VSTS, GitHub, External Git and Subversion: Build definition repository
Some tools, for example Visual Studio: Using Visual Studio 2015 and Deploying your first web app to your FREE Azure Subscription
I have been busy breaking up a monolithic service layer into about 30 small 'chunks' that can be independently deployed (C#, web API).
At the same time, we are moving to Azure.
How should these microservices be deployed?
We need 4 environments (devint, QA, UA and Prod) so we were going to use 4 slots per PaaS, and a new Paas for every microservice.
But this would get expensive and hard to manager.
Are there better approaches? (I know little to nothing about Azure so any help is appreciated).
Thanks
Azure Service Fabric is built for Microservices, and would likely be the best option to go with. Especially for forward thinking when running on the Azure platform. However, depending on your time line the fact that Service Fabric is still in Preview may be an issue. Azure features in Preview don't have the full SLA guarantee that they will when made Generally Available (GA).
The simplest hosting solution to use for Microservices in Azure App Service would be to deploy the different services as Web Apps, possibly using Web Jobs for any background processing. Web Apps and Web Jos work extremely well for building Microservices, and I have used this approach on projects in the past.
Regarding you comment about "4 slots". If you are referring to Web App Deployment Slots, then you will want to reconsider having 4 deployment slots of the same Web App to host your different environments. Especially in Production, there should be a Deployment Slot used for the Live Production instance, and one slot for a Staging area used for testing deployments before swapping them. When it comes to Dev/Int, QA and UAT then you'll want to have 1 or more Web Apps with necessary Deployment Slots to fit your needs. The last thing you want to do is mix up your Dev/Int, QA, UAT and Production environments. It's also very important to understand that all the Deployment Slots for a single Web App run on the exact same Virtual Machine; which means if you have all 4 environments as Deployment Slots then your Dev and QA environments could affect the performance of Production; which would be horrible.
You should consider using Azure Web Apps to host your chunks because it doesn't require any customization of the API or Websites you code (unlike Cloud Services which have their packaging and deployment format). The same WebDeploy mechanism will work on any IIS server (on your own server, AWS or Azure)
Take a look at Azure Resource Manager (ARM) to define the underlying resources such as the hosting App service plan (equivalent to a web server), web apps and databases. You will in all likelihood have the same set of resources in each environment and different configuration (such as different API URLs) or minor tweaks (such a premium SQL plan or larger/more instances of the web applications). ARM template can thus be shared across the 4 environments with each environment having its own ARM parameter file.
How can I publish to an Azure Website (NO VM!) using Microsoft Release Management.
At the moment, ms release management only seems to support deploying to Azure VM's. I like MS Release Management system as it lets me control my deployment variables across multiple deployment stages.
Basically, this is not a supported scenario out of the box.
Your best bet here is to use an agent-based release template with a "springboard" server to manage the release, and custom PowerShell scripts that use the Azure SDK to interact with Azure. One of my colleagues did the leg work to figure it out a few months ago, and has a few comprehensive blog posts describing how he accomplished deploying an Azure Web Application via RM.
Visual Studio Release Management now offers built-in steps to manage Azure App Services. In a Release Management process add the Azure App Service Deploy step, and configure for your website. Note that this step requires your site to be published as a .zip file.
In addition to the deploy step, it is best practice to deploy to an inactive slot, or stop / start the site using the Azure App Service Manage steps in Release Management.
For now, you should take a look at the new build system, it has an out of box task to deploy a package to azure web app.