-
Notifications
You must be signed in to change notification settings - Fork 0
The Deploy Module
You'd use the Deploy Module when you want deploy a web application package (zip) to one or more destinations. Internally it uses the Restore-WDPackage cmdlet and that in itself is just a fancy wrapper around the Web Deploy package Provider. Optionally it also uses the Sync-WDApp cmdlet to synchronize between servers and that is a wrapper around the iisApp Provider.
This introduction will show you how to:
- add the NuGet package
- trigger the execution
- discuss the default conventions
Let's begin!
You can either:
- use NuGet
Install-Package WDP.Deploy
. (preferred way)
- note: this installs a solution-level NuGet package and the PS file will be placed in the
packages
folder.
- or manually download the PS file to a desired location.
- import the PS module:
Import-Module [PATH_TO_PSMODULE_ROOT_FOLDER]\wdp.deploy.psm1
- note:this assumes that the name of the PS file is
wdp.deploy.psm1
- invoke the deploy function:
Invoke-Deploy [PATH_TO_WEBAPPLICATIONPACKAGE_ROOT_FOLDER]\myapp.zip
- note: this example deploys/pushes the web application package (
myapp.zip
) to the local (localhost) IIS application/site described inside the package. See below:
- The path to the web application package (zip) that you wish to deploy is required.
- The destination IIS site/application will be determined by:
1) the package itself. (like example above)
2) by overriding the 'IIS Web Application Name' parameter by supplying a parameters file (see examples).
WDP.Deploy
is built with conventions, before/over configuration, in mind which means that it assumes a lot of things in order for you to not get lost in configuration hell right away.
However it is important that you have knowledge about the conventions, the defaults, that we're assuming. If you don't like them just change them by overriding one or more of the properties that you see below.
default: optional [not set by default]
If you wish to deploy to one or more remote servers use this property that will accept an array of the paths to .publishsettings files that represent these servers.
The convention is:
The first .publishsettings file
in the array will be treated as the primary server and thus deployed to first.
If you supply more that one file the remaining will be treated as "slaves" and thus synced with the primary server.
See 'UseSync' for how to turn it off.
default: optional [not set by default]
The web deploy package provider creates (or can create) parameters that you must/can override when restoring the package. The easiest way to accomplish this is via a file called the parameters file (an xml file). This property contains the path to that file.
The format of the file is:
<parameters>
<setParameter name="name1" value="value1" />
<setParameter name="name2" value="value2" />
</parameters>
default: optional [not set by default]
Custom Provider Settings that you can enable. Read more on the package Provider.
default: optional [not set by default]
Folders you want to skip during a deploy.
default: optional [not set by default]
Files you want to skip during deploy.
default: true
By default, if you use more than one 'DestinationPublishSettings' file, we will sync from the primary to the slaves. (see 'DestinationPublishSettingsFiles' for more information).
If this property is set to false we will instead push the package to all locations instead of using sync.
default: true
Debug messages is a better word for this perhaps. By default we will log some extra information. If you execute within TeamCity these messages will be formatted to work with TeamCity.
If you turn this off, there will be no extra information logged.