Skip to content
This repository has been archived by the owner on Sep 4, 2024. It is now read-only.

Deploying inplace and without repository

Jump to bottom
JennyLawrance edited this page Dec 9, 2021 · 19 revisions

Overview

There are a couple of settings that can be used to optimize the deployment. Below describes what those are and how one or more can be used to fit your scenario.

Settings

  • SCM_REPOSITORY_PATH

This represents the repository path. The value can either be absolute path (such as d:\home\site\myfolder) or a relative path of site directory; for instance, myfolder setting means d:\home\site\myfolder. The default is repository; meaning the repository will be created at d:\home\site\repository folder.

  • SCM_NO_REPOSITORY

This indicates whether repository should be created with source control (Git/Hg). By default, the source control is always enabled. With an overhead of additional source control files and functionalities, the benefit is one can rollback and deploy from a certain changeset id in the history. If set to 1, no source control is enabled and deployment history will only be read-only (not rollback-able). However, there is no overhead of source control (faster deployment). Setting this to '1' effectively ensures no git deployment can occur. All git deployments after SCM_NO_REPOSITORY is set to '1' will result in a 400 error. Only dropbox can be used with this setting since it has no source control.

  • PROJECT

This indicates which sub folder in the repository folder to be deployed. This is often used where there are multiple projects in the repository, this knob will dictate which project/folder to be deployed. The default is .; meaning deploying from the root of repository.

  • SCM_TARGET_PATH

This indicates which folder to deploy to. The value can either be absolute path (such as d:\home\site\myfolder) or a relative path of wwwroot directory; for instance, myfolder setting means d:\home\site\wwwroot\myfolder. The default is .; meaning deploying to d:\home\site\wwwroot.

Scenarios

Given the above 4 settings, one can use in combination to achieve interesting scenarios.

Inplace deployment

By setting SCM_REPOSITORY_PATH to wwwroot, the repository (artifact source) and wwwroot (destination) folders are the same! The benefit is there is no need to copy from repository (or temporary folder in case of msbuild) to wwwroot. This speeds up the deployment especially for sites with many files and only a few changed for each deployments. This is very suitable for site (aka. Basic Web Site) that requires no msbuild.

By the way, this mode is turned on automatically when the git clone\fetch is occurred for site initially deployed by msdeploy (gallery) as well as ftp deploy.

Note: When using Inplace deployment in App Service Linux, take additional steps in code/config of the application to make sure the contents of .git folder is not served as static content.

Inplace deployment with readonly history

By setting SCM_NO_REPOSITORY to 1, the default SCM_REPOSITORY_PATH will auto adjust to wwwroot. This allows inplace deployment without any source control overhead. This is suitable for deploying from Dropbox where you simply want to file-to-file sync up as is with wwwroot and no source control.

Deploy from a subfolder of a repository

By setting PROJECT, you can define from which subfolder in repository to deploy. See Customizing deployments.

Deploy to a subfolder of a wwwroot

By setting SCM_TARGET_PATH, you can define to which subfolder in wwwroot to deploy.

Deploy from a subfolder of a repository to a subfolder of a wwwroot

Simply use a combination of PROJECT and SCM_TARGET_PATH #664

Notes

See these steps from a forum user who uses in-place deployment for a specific scenario.

How to turn off in-place deployment?

In some situations, in place deployments might not be suitable for use in production scenarios. One specific scenario where in-place deployment is not recommended is where the web app is configured to serve static files. If proper attention is not taken to the app's code/configuration, the files in .git folder will end up getting served as static content. To migrate away from in-place deployments, follow the below steps.

  • git clone to a local directory to backup current content
  • Login to the SCM endpoint (appname.scm.azurewebsites.net)
  • Navigate to equivalent command prompt:
    • Linux: SSH/Bash
    • Windows: Cmd/Powershell
  • Look for file settings.xml in deployment folder:
    • Linux: /home/site/deployments/
    • Windows: D:\home\site\deployments

If settings.xml is found

  • Confirm if the SCM_REPOSITORY_PATH is set to wwwroot
  • Change the value of SCM_REPOSITORY_PATH to repository or remove the line with the key SCM_REPOSITORY_PATH.
  • Migrate the .git content to the repository folder
    • Linux: mv /home/site/wwwroot/.git /home/site/repository/
    • Windows: move d:\home\site\wwwroot\.git d:\home\site\repository\
  • Verify repository is in a good state:
    • git pull
    • git log

If the settings.xml is not found:

  • Create a new settings.xml file with the following content
    • Linux: /home/site/deployments/
    • Windows: D:\home\site\deployments 
<settings>
  <deployment>
    <add key="SCM_REPOSITORY_PATH" value="repository" />
  </deployment>
</settings>
  • Migrate the .git content to the repository folder
    • Linux: mv /home/site/wwwroot/.git /home/site/repository/
    • Windows: move d:\home\site\wwwroot\.git d:\home\site\repository\
  • Verify repository is in a good state:
    • git pull
    • git log
Clone this wiki locally