When we try to deploy web app to a deployment slot in app service plan(created inside app service environment) it removes the existing code in both production and staging slot and then it deploys the code in staging slot. Because of this our old code is not available in staging slot when we swap. Are we not supposed to use slot in ASE ? If yes, how can we fix this issue ?
We faced the same issue which was resolved after changing the task version of Azure App Service deploy task in the release pipeline. Earlier we were using the task version 4 which has option 'Deploy to slot or ASE' which seems to cause the issue. When you select task version 3, you will get the option 'Deploy to slot' after which the release works fine and the code is not deleted from staging or prod slot.
Deployment slots are pretty standard and easy to use.
It sounds like your deployment process is broken and is not properly deploying in the correct sequence which is causing this issue.
I would suggest investigating your deployment process and taking it step by step and validating each step manually.
Edit:
The documentation you linked below is somewhat confusing to me however this looks to be the configuration you should try:
DeployToSlotOrASEFlag = TRUE
(We want to deploy to an ASE, so we must set TRUE)
SlotName = staging
(Required, if DeployToSlotOrASEFlag = true)
Default value: production
Related
I have developed a number of JavaScript functions that all get deployed to an Azure Function App. I have two different code sets intended for two different Azure FAs. Unfortunately, when the FAs were created they were not given a meaningful name, and instead are just a random string of letters and numbers.
I primarily deploy my code to Azure from within VSCode, and that seems to work fine. However, I have a strong concern that one day I will deploy one set of functions to the wrong FA, which would of course cause big problems.
Is there anywhere that I can define a list of "allowed" function apps, so that if I were to attempt deploying the code to another FA it would fail? Or is there another method to achieve a similar result?
As of right now, I can deploy any codebase to any FA.
To prevent deploying code to the wrong function:
There are few methods for restricting deployment to only particular Function Apps and preventing deployment to undesired Function Apps.
Use Deployment slots:
As detailed in MSDoc, You can choose a deployment slot for a function app which has a different URL than function app.
Instead of executing immediately in a production environment, you can test any fixes or incorrect deployments in a different deployment slot before it goes live by deploying it into a secondary deployment slot.
Because it is your production environment slot, your users will be accessing your original Function App.
How to work with Deployment Slots:
Goto Function App and you will find Deployment slots under deployment and then Add a slot as described in the below image:
You can also create a deployment slot using Az CLI command az functionapp deployment slot.
Use below format:
az functionapp deployment slot create --name <Functionapp> --resource-group <ResourceGroup> --slot "slot1"
Use Deployment Scripts:
When you deploy your code, you can specify a deployment script, which can be a CLI or PowerShell script.
You can create a deployment script that verifies the target Function App's name and fails if it does not match one of the given Function Apps.
Goto Azure Portal and search for Deployment Scripts to work with this.
I am currently planning on a type of multi-tenant system, were different resource groups with a set of AppServices are deployed for customers via ARM Templates. Hence, each customer has its own Resource Group and set of AppServices. Currently we use Azure DevOps to deploy to a set of AppServices used for Development and Quality Assurance before it gets to Production. I am now trying to incorporate DevOps into the mix, automating a pipeline creation of some sort... (it would be a copy of an existing pipeline but only changing the Target AppServices). Which is were my question comes from, Is there a way to dynamically create or edit a Release pipeline to add the deployment of those new AppServices, without the need of manually edit or create a pipeline an adding those newly created AppServices, I was thinking something around the lines of being able to copy a yaml file template then replacing the necessary info to point to those AppServices after they have been created, but I am not totally sure where could I store the new yaml file so that it is picked up by Azure DevOps, or how could I would accomplish these, with the main idea being that all of this continues to be part of an automated process (if possible).
Thanks a lot for any help, any suggestion is appreciated.
EDIT:
The question is not about how to Deploy an ARM Template through the DevOps release pipeline (I plan on using a PowerShell Script/REST API to accomplish that), instead, is about when the AppServices Resources are created, I need to deploy code to those newly created AppServices and also update that code when necessary (Hopefully through a Release Pipeline), somehow generate a new release pipeline each time I deploy a new set of Resources. So that, when there is a new update, I could easily have that pipeline triggered and that set if AppServices can be updated (created as part of the automation process "dynamically"). (I Already have a similar pipeline that deploys to a "static" set of AppServices).
This is possible as you eluded to with YAML Pipelines. Based upon the scenario you have subscribed each repository would have it's own pipeline.yml file that will define the trigger, pool etc. It would also reference a repository that will house your yaml template.
The template would accept whichever parameters you may required (resource group, app service name, etc...) The triggering pipeline associated with each repository would pass this information leveraging the teamplate.
By doing this CI/CD can be set up to trigger on the individual pipelines and deploy the appropriate code all while leveraging the same YAML template.
The repository reference would be similar to:
resources:
repositories:
- repository: YAMLTemplates
type: git
name: OrginazationName/YAML Project Name
With the call to the template being similar to:
- template: azure-ARM-template.yml#YAMLTemplate
parameters:
appServiceName: 'AppServiceName'
resourceGroupName: 'ResourceGroupName'
UPDATE
At a high level the YAML pipeline would consist of the following. If all App Services are similar as stated and ARM Templates are similar this how it could be constructed and triggered based on a folder path:
Build necessary artifacts
Publish Pipeline
Deploy Azure Resource Group Task
Deploy App Settings Task (if applicable)
Deploy App Service
Release the deployment pieces for each environment in appropriate stages to help alleviate the amount of copying and pasting each of the above tasks can be part of a template either individually at a task, combination of tasks, or all in one. This would allow for defining the YAML once and referencing it and including app specific components as needed as parameters to the templates.
When creating a function in Azure through a Linux environment it seems CI/CD is completely missing from it's capabilities as I can't see any actual files. My VS code tells me this
Error: This plan does not support viewing files.
and when I try to deploy my files to the server through the Azure pipeline everything works except for the
Azure App Service Deploy
Which tells me this.
2020-04-21T19:48:37.6676043Z ##[error]Failed to deploy web package to App Service.
2020-04-21T19:48:37.6689536Z ##[error]Error: Error: Failed to deploy web package to App Service. Conflict (CODE: 409)
I did get it working directly through VS Code with a windows environment and didn't notice any of those issues.
Can you confirm this is not possible through Linux or perhaps there is a solution for what I am looking for.
is it possible to do continuous deployment CI/CD of an Azure Function through a Linux Environment via Azure DevOps?
The answer is Yes.
To deploy a Azure Function, you should use Azure Function App task instead of Azure App Service Deploy task. For below example.
steps:
- task: AzureFunctionApp#1
inputs:
azureSubscription: '<Azure service connection>'
appType: functionAppLinux
appName: '<Name of function app>'
#Uncomment the next lines to deploy to a deployment slot
#Note that deployment slots is not supported for Linux Dynamic SKU
#deployToSlotOrASE: true
#resourceGroupName: '<Resource Group Name>'
#slotName: '<Slot name>'
Please check out this document Continuous delivery by using Azure DevOps for detailed examples.
In Release Management on Visual Studio Team Services I receive the following error:
"Code": "Conflict",
"Message": "The slot cannot be changed because its configuration settings have been prepared for swap.",
"ExtendedCode": "04081",
"MessageTemplate": "The slot cannot be changed because its configuration settings have been prepared for swap.",
From my Release management template in the "Azure Deployment" step, I have the following configuration:
Azure connection type: Azure Resource Manager
Action: Create or update Resourcegroup
Deployment mode: incremental
We have an ARM template with only appsettings we want to have applied to the production slot. the previous step in this release is a "Swap"
More info: we first release to some test slots, then a QA slot, which swaps with PROD.
This first occurred with a scheduled release (at midnight)
The slots are like this:
QA:
some steps (like blob copy),
final step: deploy a complete ARM template which creates the resources
PROD:
step 1: SWAP, with Azure App Service Manager (Preview)
step 2: ARM template with only AppSettings
Even a new build (which triggers a new release) still causes this error, any hints/clues?
I was able to figure out the root cause of this issue. If the Azure App Service Manager (Swap step) fails for some reason, in that case, Swap action does not get completed and leaves the App Service in inconsistent state.
If you go to the Azure portal and see the Overview of your App Service, 'Complete Swap' option is enabled instead of 'Swap'. Hence we should first Cancel or Complete the incomplete Swap. After doing that the deployment just works fine without this error.
We seemed to have this resolved
with only running step 2 in PROD (not perform a swap)
using another admins credentials
after trying several days
Not sure yet which one was the culprit.
The Azure App Service Manager (Preview) was used as a swap step
I'm trying to deploy a package on a role using UpgradeBySlotAsync on IDeploymentOperations' Deployments. When the deployment doesn't exist, it throws saying: 'A virtual network site cannot be added or removed during deployment update or upgrade'.
If I want to check on deployment's existence using GetBySlotAsync, it also throws when the deployment is not there.
Is there a way to check whether there is a deployment on Staging using IDeploymentOperations type? Something similar to Get-AzureDeployment in Powershell.