The fact that AppVeyor deployment requires build artifacts on input makes the deployment process predictable and repeatable.
AppVeyor allows you to deploy using multiple providers as part of the build process (inline deployment) as well as promote builds to existing environments (environment deployment).
Inline deployment runs as the last phase in the build pipeline and allows the configuration of multiple deployments running synchronously one-by-one with results in the build console.
Environment deployment is triggered manually or through the API to deploy a “green” build to an existing environment. A new deployment is registered within a project/environment with results in the deployment console. If you don’t have any existing environments, you can create one at https://ci.appveyor.com/environments.
The table below summarizes the key differences between the two modes with lists of deployment providers available in each mode:
|Inline deployment||Environment deployment|
|Deploys local artifact files||Deploys artifacts from cloud storage|
|Build console||Deployment console|
|Do not register deployment||Register new deployment|
|FTP, SFTP||FTP, SFTP|
|Web Deploy||Web Deploy|
|SQL Database (SSDT)||SQL Database (SSDT)|
|Azure WebJob||Azure WebJob|
|Azure App Service Zip Push||Azure App Service Zip Push|
|Azure Blob||Azure Blob|
|Azure Cloud Service||Azure Cloud Service|
|Amazon S3||Amazon S3|
|Amazon Elastic Beanstalk||Amazon Elastic Beanstalk|
|GitHub Releases||GitHub Releases|
You can use standard and custom environment variables in provider settings, for example you can set a remote FTP folder as
$(appveyor_build_version) will be replaced with the current build version.
after_deploy scripts are disabled by default on Pull Requests. Deployments on Pull Requests can be enabled with
Enable deployments in Pull Requests UI-only checkbox in the General project settings tab.
When you deploy as part of the build process you can control the conditions under which a deployment should be run.
By default, AppVeyor deploys from all branches, but you can include only specific branches. Also, you can use any environment variables to have more complex conditions.
For example, to deploy from the “master” branch and only artifacts built for the “x86” platform (
platform is the name of an environment variable):
- provider: Environment name: production on: branch: master platform: x86
By default AppVeyor starts a new build on any push to GitHub, whether it’s a regular commit or a new tag. Repository tagging is frequently used to trigger deployment.
AppVeyor sets the
APPVEYOR_REPO_TAG environment variable to distinguish regular commits from tags - the value is
true if the tag was pushed; otherwise it’s
false. When it’s
true the name of the tag is stored in
You can use the
APPVEYOR_REPO_TAG variable to trigger deployment on tag only, for example:
- provider: Environment name: production on: APPVEYOR_REPO_TAG: true # keep casing this way for Linux builds where variables are case-sensitive
However, please note that in case of annotated tag,
appveyor_repo_tag are mutually exclusive. This is because, for webhook created as a result of annotated tag, there is no practical reliable way to recognize what branch the tag was created from. Therefore with this setting deployment will happen only for the master branch:
- provider: Environment name: production on: branch: master # only this will work APPVEYOR_REPO_TAG: true # condition will never be evaluated for annotated tag
So if you need to deploy on both branch and annotated tags, please create two
provider sections under
deploy like this:
deploy: - provider: Environment name: production on: branch: master - provider: Environment name: production on: APPVEYOR_REPO_TAG: true
You can disable builds on new tags through the UI (General tab of project settings) or in