Skip to content

Latest commit

 

History

History
133 lines (92 loc) · 4.19 KB

DEPLOY.md

File metadata and controls

133 lines (92 loc) · 4.19 KB
Raw

Deploy Overview

Deploy usage guide and design decision.

Multi-stage, multi-region deploy

By default, all functions are deploy to a stage (dev) and a region. The autogenerated resource group name will reflect this information. The name follow the Microsoft recommended naming convention.

Using exitsing resource group

sls deploy -s dev -r westus2 -g myResourceGroup

  • Use resource group myResourceGroup
  • Create/Update app service plan, app service
  • Zipdeploy code

Tagging resource group

To apply tags to your resource group, you can specify them in your provider config as such:

...
provider:
  tags:
    TAG_1: tagValue1
    TAG_2: tagValue2

Existing tags with the same names will be updated. Existing tags (with different names) will not be removed.

No resource group specified

sls deploy -s dev -r westus2

  • Create if not exist resource group <service>-dev-westus2-rg
  • Create/Update app service plan, app service
  • Zipdeploy code

Design decision on resource group support

Specifying resourceGroup in serverless.yml

  • it is not clear if a resourceGroup has already been associated with a given stage and region.

For example, we have the following default config

provider:
  stage: dev
  region: westus
  resourceGroup: myResourceGroup

then user try to deploy sls deploy -s prod -r westus

  1. Do we use the environment variables / creds associated with dev or prod?
  2. Someone new to the codecase see both the serverless.yaml and the command in a CD script, how can they tell which resourceGroup goes where.

Specifying resourceGroup in command line

sls deploy -s prod -r westus -g prodResourceGroup

  1. With this format, it's more clear which stage+region combo is associated with a resourceGroup.
  2. User can still make mistake, however, and use the wrong resource group for a specific stage.

Don't support user defined resource group

  1. always using the right resource group
  2. restrictive for user who have already defined their resources

Specifying storage acount in serverless.yml

  1. can specify storage account for your Azure Functions
  2. specified storageAccount need to be unique
  3. default storageAccount is sls<region><stage><6-char resource group hash>
provider:
  stage: dev
  region: westus
  resourceGroup: myResourceGroup
  storageAccount:
    name: myStorageAccountName

Deployment Methodologies

1. Deployment to Function App

  • Deploy resource group, upload packaged artifact directly to function app. Sets function app RUN_FROM_PACKAGE setting to 1.

2. Deployment to Blob Storage

  • Deploy resource group, upload packaged function app to blob storage with version name. Sets function app RUN_FROM_PACKAGE setting to path of zipped artifact in blob storage
  • Default container name - DEPLOYMENT_ARTIFACTS (configurable in serverless.yml, see below)

Deployment configuration

service: my-app
provider:
  deployment:
    # Rollback enabled, deploying to blob storage
    # Default is true
    # If false, deploys directly to function app
    rollback: true
    # Container in blob storage containing deployed packages
    # Default is DEPLOYMENT_ARTIFACTS
    container: MY_CONTAINER_NAME
    # Sets the WEBSITE_RUN_FROM_PACKAGE setting of function app
    # to the SAS url of the artifact sitting in blob storage
    # Recommended when using linux, not recommended when using windows
    # Default is false
    runFromBlobUrl: true

plugins:
  - serverless-azure-functions

package:
  ...

functions:
  ...

If rollback is enabled, the name of the created package will include the UTC timestamp of its creation. This timestamp will also be included in the name of the Azure deployment so as to be able to link the two together. Both names will have -t{timestamp} appended to the end.

Sequence diagram for deployment to blob storage

alt text

Sub-Commands
  • sls deploy list - Logs list of deployments to configured resource group with relevant metadata (name, timestamp, etc.). Also logs versions of deployed function app code if available