Application deployment isn’t usually triggered by human interaction. Typically it is executed automatically as part of a CI/CD pipeline. Jaws Deploy facilitates integration into existing CI/CD environments by exposing a simple HTTP API.
Note: JawsDeploy API contains minimal amount of endpoints which only cover control over deployments. More endpoints related to infrastructure will be implemented gradually over time as we expand our platform.
You can call API endpoints directly from your build pipeline using your preferred language and coding style. Please refer to our API Reference for more details.
If your builds are based on PowerShell or your CI platform supports PowerShell it is recommended to take advantage of our PowerShell SDK which is a very lightweight, zero-dependency wrapper over Jaws Deploy Rest API. You can find it in our GitHub repository: JawsDeploy/powershell-sdk (github.com)
Here is a short snippet which deploys a specific project to Staging environment using service-account authentication:
$env:JAWS_API_LOGIN = "service_account_id"
$env:JAWS_API_PASSWORD = "SecretPa55w0rd"
Import-Module -Name JawsDeploySdk.psm1
$projectId = "id_of_a_project_to_deploy"
$version = "version_generated_during_the_build" # e.g. "5.27.1-RC2"
$resp = Invoke-ReleaseAndDeployProject -projectId $projectId -version $version -environmentName Staging
Write-Host $resp
- Go to your desired Workspace and Create a Cloud Account (Cloud Accounts menu item in the left pane).
TenantID and SubscriptionID are available in Azure portal (search for “Tenant Properties” and “Subscriptions” blades).
ApplicationID is the ID of your application in Azure App Registration, it is also called Client ID. You will use it to authenticate Jaws Deploy against your Azure account. Go to “App registrations” blade in Azure and create a new app called Jaws Deploy or something that you can recognize later as the application required for Jaws Deploy access. Once created the Application (Client) ID is available in the app overview.
Having the app registration open go to “Certificates and Secrets” blade, then “Client secrets” tab and create a new secret. Specify its name and expiration date. After creating copy the secret, as you won’t have access to it later.
Put the secret in the “Application password” field of the Jaws Deploy Cloud Account. - With the Cloud Account ready go to JawsDeploy Azure Web Apps page and click “Add new cloud target”. These targets represent your Azure Web Apps. Even if you are using Azure Deployment Slots - create just one App. Slots will be configured later, at the deployment stage.
Select the appropriate account in the “Azure Web App settings - Account” dropdown.
After account is selected the system will list all available Azure Web Apps. Select one app and submit the form.
- Azure deployments with JawsDeploy are based on the concept of a single worker that runs all the deployment logic and pushes specified package to one or many Azure Web Apps. A worker is just one of your Machines in JawsDeploy. You can identify workers by adding specific tags to your machines.
Note: currently Jaws Deploy does not provide hosted cloud workers, but relies on your infrastructure. You need to go to Machines and create a Machine in Jaws Deploy, follow instructions and install Jaws Deploy Agent on your designated machine / VM. Then ideally create a tag which will let you identify this machine later as a Worker. Tag name is up to you. - When you worker is ready - create a project and add a step of type “Deploy Azure Web App”.
Note that in Execution Flow section the Run On input is locked on value “Cloud targets via Worker”.
In the Worker Tag dropdown select the tag you assigned to your worker Machine. You if you have multiple machines tagged with the same tag - Jaws Deploy will pick one machine automatically when deployment runs (it will look at how busy the machines). This machine will run deployment scripts against all eligible Cloud Targets.
If you don’t want to deploy to all Azure Web Apps in your workspace - then it is necessary to specify some tags in the “Use only cloud targets that have specific tags assigned” section. Using those tags Jaws Deploy will filter out those Cloud Targets that should be included in the deployment. You can also think about those tags as “Roles” of your Cloud Targets (e.g. one target is your “Ecommerce frontend” while another could be “CMS app” - in that case you would have 2 tags that reflect these 2 roles).
Specify the package to be deployed - either package that has been pushed to JawsDeploy package store (preferred) or from external NuGet feed. Package stor is built-in. NuGet feeds is something you need to add to your workspace manually. It could be e.g. a TeamCity NuGet feed where your binary packages reside.
If you use Deployment Slots then you should specify a variable in the Deployment Slot field in this project step. First add a variable to your project e.g. MyWebAppDeploymentSlot. It would be empty for production environment, and it would be specified for e.g. Staging with the name of your Slot as defined inside Azure.
You can also specify both AppSettings and Connection strings below - just be careful, as these definitions are replacing all existing app settings and connections strings. If you do not want this behavior - leave those fields empty and use config transforms that are available below (variable replacement, config transforms as we know it from .NET apps and also structured JSON config updates). - Create a release and deploy it.
- If you need to do perform any additional logic - you can add more steps of type “Azure Script”. This kind of step lets you define arbitrary PowerShell code that will run in the context of your specified Azure Account - this step includes an Azure Account selector. This step also supports both modes - either execute it once on a specific worker, or you can also choose to run the script multiple times, on a single worker, but once for every matching Cloud Target.
Jaws Deploy will automatically install all required PowerShell Az.* modules when running any of the Azure-scoped steps.
