After a failed Azure Deploy, our deployed AppService is empty

Question

We have a Azure DevOps pipeline that first deploys our resources using ARM-templates and then deploys our AppServices using zips. We've run the pipeline multiple times, and the application is correctly running.

Sometime after in another deployment attempt - the first deployment step (of the resources) fails. The changes in the deployment do not contain any changes to the AppService. And the failed part is not the AppService (but instead say our database), the AppService still becomes unavailable. And it looks like it has reset to the deafult hosting settings. It seems the previous deployments are still available in the "/data/SitePackages" folder, but the "/site/wwwroot" folder contains only the default "hostingstart.html" file.

My understanding from an incremental deployment is that if the AppService is unchanged it should keep all it's settings! (And thus it's previous deployment active.)

Is this default behaviour? Can we somehow keep the previous App running when part of the deployment fails? Do we need to choose another deployment strategy?

Our pipeline looks something like this;

jobs:
  - deployment: 'Deploy'
    environment: '${{ parameters.environment }}' # The environment to use in Azure Devops (controls the required approvals)
    variables:
      - template: '../variables/deploy-variables.yml'
        parameters:
          environment: '${{ parameters.environment }}'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureResourceManagerTemplateDeployment@3
            displayName: 'Azure - Deploy resources'
            inputs:
              deploymentScope: 'Resource Group'
              azureResourceManagerConnection: '${{ parameters.azureServiceConnection }}'
              subscriptionId: '$(azureSubscriptionId)'
              action: 'Create Or Update Resource Group'
              resourceGroupName: '$(resourceGroup)'
              location: 'West Europe'
              templateLocation: 'Linked artifact'
              csmFile: '$(Pipeline.Workspace)/drop-resources/files/arm/resources/azuredeploy.json'
              csmParametersFile: '$(Pipeline.Workspace)/drop-resources/files/arm/resources/azuredeploy.parameters.json'
              deploymentMode: 'Incremental'

          - task: AzureWebApp@1
            displayName: 'Deploy Service'
            inputs:
              azureSubscription: '${{ parameters.azureServiceConnection }}'
              appName: '$(serviceName)'
              package: '$(Pipeline.Workspace)/drop-app/archives/Service.zip'

score 1 · Answer 1 · answered Feb 26 '21 at 09:17

1

This is expected. Your pipeline is doing two things, deploying the app service, then deploying your app. If the first part succeeds it deploys an app service with default files, if your second step fails then it will be left in that state.

This should only happen on first deployment. If you run a subsequent deployment where the first step succeeds it will not overwrite the existing files in the web app, it will leave them as is. If your second step fails then the old files should still be there, unless your second step failed part way through and overwrote some of the files.

If you want to ensure you have an option to roll back to the previous version even if the files do get overwritten then you should look at using deployment slots.

answered Feb 26 '21 at 09:17

Sam Cogan

38,158
6
77
113

Thanks this is kind of undocumented imho. I know of deployment slots, we will be using it in the future. – Kolky Feb 26 '21 at 13:22
How is it undocumented? How would the Web App contain your code if it failed before the step that uploads your code? This is working as expected – Sam Cogan Feb 26 '21 at 13:23
Because the zips of the previous deployment are still on the app-service. And the deploy of the Web App did not fail. Why would it not retain the previous application during a new deployment? – Kolky Mar 01 '21 at 09:14
It does, your question states "However when our first deployment (of the resources) fails" if it fails the first time, then you have never run the second step to upload the zips – Sam Cogan Mar 01 '21 at 09:15
1

Still I find it strange that after I do an incremental ARM-template deployment. Without ANY changes to the AppService, the deployment in question succeeds for 95% just one other dependency (in this case the database) fails to successfully deploy and causes the pipeline to fail. The AppService is then reset to the default welcome page, while all the previous deployment zips are still to be found in the FTP. To me incremental means that if I do not change the AppService it should retain it's previous deployment. – Kolky Mar 01 '21 at 19:55
Sorry, I made a mistake in my question, I've updated the sentence in question. To be clear we've run the pipeline multiple times without failure. Not sure if your answer is now correct. – Kolky Mar 01 '21 at 20:01

score 0 · Accepted Answer · answered Apr 13 '21 at 11:36

I've solved the issue myself by adding the following app-settings to the resource (arm) deployment;

"WEBSITE_ENABLE_SYNC_UPDATE_SITE": "true",
"WEBSITE_RUN_FROM_PACKAGE": "1",

This keeps the current package as active, previously these app-settings we're removed while the package was still available.

After a failed Azure Deploy, our deployed AppService is empty

2 Answers2