Microsoft Azure custom deployment environments

IP Systems Solutions best practices approach

Deployment Components

This following section introduces the three main components that IP Systems Solutions assists for deploying to App Service: deployment sources, build pipelines, and deployment mechanisms.

Deployment Source

A deployment source is the location of an application code. For production apps, the deployment source is usually a repository hosted by version control software such as GitHub, BitBucket, or Azure Repos. For development and test scenarios, the deployment source may be a project on a local machine. App Service also supports OneDrive and Dropbox folders as deployment sources. While cloud folders can make it easy to get started with App Service.

Build Pipeline

Once a decizion made on a deployment source, IP Systems Solutions builds a pipeline. A build pipeline reads the source code from the deployment source and executes a series of steps (such as compiling code, minifying HTML and JavaScript, running tests, and packaging components) to get the application in a runnable state. The specific commands executed by the build pipeline depend on the language stack. These operations can be executed on a build server such as Azure Pipelines, or executed locally.

Deployment Mechanism

The deployment mechanism is the action used to put the built application into the /home/site/wwwroot directory of the web app. The /wwwroot directory is a mounted storage location shared by all instances of the web app. When the deployment mechanism puts the application in this directory, the instances receive a notification to sync the new files.

Deployment Slots

IP Systems Solutions uses deployment slots when deploying a new production build. When using a Standard App Service Plan tier or better, deploy the app to a staging environment, validate all changes, and do smoke tests. When is ready, swap staging and production slots. The swap operation warms up the necessary worker instances to match production scale, thus eliminating downtime.

Continuously Deploy Code

IP Systems Solutions will assist if a project has designated branches for testing, QA, and staging, then each of those branches should be continuously deployed to a staging slot. (This is known as the Gitflow design.) This allows stakeholders to easily assess and test the deployed branch.

Continuous deployment should never be enabled for an production slot. Instead, the production branch (often main) should be deployed onto a non-production slot. When is ready to release the base branch, swap it into the production slot. IP Systems Solutions approach is to swap into production instead of deploying to production prevents downtime and allows to roll back the changes by swapping again.

Continuously Deploy Containers

For custom containers from Docker or other container registries, IP Systems Solutions deploy the image into a staging slot and swap into production to prevent downtime. The automation is more complex than code deployment because the image must be pushed to a container registry and update the image tag on the webapp. For each branch IP Systems Solutions deploy to a slot. IP Systems Solutions sets up anautomation and perform the following on each commit to the branch.

Build and tag the image: As part of the build pipeline, tag the image with the git commit ID, timestamp, or other identifiable information. It's best not to use the default "latest" tag. Otherwise, it's difficult to trace back what code is currently deployed, which makes debugging far more difficult.

Push the tagged image: Once the image is built and tagged, the pipeline pushes the image to our container registry. In the next step, the deployment slot will pull the tagged image from the container registry.

Update the deployment slot with the new image tag: When the property is updated, the site will automatically restart and pull the new container image.