...
Build Workflow
Navigate to the Workflows tab
Select the “+” button from the left-hand pane to create a new workflow with type as Build.
...
Deploy Workflow
navigate to the Workflows tab
Select the “+” button from the left-hand pane to create a new workflow with type as Deploy.
...
If we look inside the deploy.zip, it contains the source code only. Basically, it contains the source code files that need to be copied to the Azure Web App backend. Azure Web App treats this as an executable package and runs it.
...
Note: the source code(or any executable files) inside the note: Each application will have separate directory structure/file name hence the all paths need to be modified accordingly.
note: Its essential to make sure Consumes Artifacts and Produces Artifacts checkbox is marked only when required. Please follow the snapshots for all execution steps to avoid any discrepancy.
note: the source code(or any executable files) inside the .zip file shouldn’t be inside any subfolder. Else once the zip file is deployed to Azure Web App, it may not work.
...
Navigate to the Project tab and create a Project with a logical name(Node.jsAzureWebApp NodeJsAzureWebApp in this case)
...
Configure the Build and Deploy workflow that has been created in previous steps as shown below.
...
Application Setting and Connection String values will be updated against the Web App Slot Name configured at the environment level. Refer to the Deploy to Slot section for further details.
Target Properties
Select Topology from the menu and then select Topology Overview from the left menu. You will see a table that has Instances as the rows and Environments as the columns with colored circles representing the Environment Instance. Color coding represents:
...
RED - no required properties are set and/or the Endpoint is not configured
There could also be scenarios where someone only need to update the Application Setting or Connection String without actually deploying the code. In that case one can use upsertWebAppApplicationSetting or upsertWebAppConnectionString operations respectively. The workflow execution will be exactly same only the code archive creation /Docker image update step will not be required. Build workflow generated artifact should only container AppSetting.json or ConnString.json. These values can also be passed as input as already mentioned in detail in above section.
Target Properties
Select Topology from the menu and then select Topology Overview from the left menu. You will see a table that has Instances as the rows and Environments as the columns with colored circles representing the Environment Instance. Color coding represents:
RED - no required properties are set and/or the Endpoint is not configured
YELLOW - some of the required properties are set and/or the Endpoint is not configured
GREEN - all required properties are set and the Endpoint is configured
...
Properties | Mandatory Field | Description |
|---|---|---|
Web Slot Name |
| Target slot for deployment |
Target Slot to swap | Optional | In case slot swap is required |
Azure Cloud Account |
| Azure account with relevant details |
Absolute path of Azure CLI | Optional | Not required if Azure CLI already added to workflow execution m/c class path |
...
GIT Path | Optional | Path to the Git executable. Required only if git is not on class path. |
Below given are the environment-specific values which need to be updated.
...
Azure Web App default slot is production. However, one can configure multiple slots and deploy web application on those slots inside App. Web App Slot Name is a mandatory field, where the code needs to deploy.
In case someone wants to do a slot swap, they can provide the Target Slot to swap with as shown below.
...
executeWebAppSlotSwapoperation can be used to perform the slot swapthe code needs to deploy.
In case someone wants to do a slot swap, they can provide the Target Slot to swap with as shown below.
...
executeWebAppSlotSwapoperation can be used to perform the slot swap.
Post deployment debugging
Post deployment success of plugin execution it can take a little while for the web application up and running.
Currently once the application is deployed to Azure WebApp through the plugin operation, Azure basically uploads the files to the backend. However if the application is up and running or have failed, can’t be verified immediately. It takes a little while for the service to start and accept requests.
Issues can happen due to various issues starting from incorrect configuration or structure issue.
Best way to check logs: https://$webapp_name.scm.azurewebsites.net/api/logstream or logstream from console or https://$webapp_name.scm.azurewebsites.net/api/logs/docker
So in case the Web App Url is : https://webapp0610.azurewebsites.net
The log can be accessed at -https://webapp0610.scm.azurewebsites.net/api/logstream
or check the docker log files under https://webapp0610.scm.azurewebsites.net/api/logs/docker
In case of failure we can easily debug the issue from log.
Build Execution
For detailed steps on how to initiate Build Azure Web App, review artifacts, and ultimately deploy to Azure Web App please refer to Build and deploy execution through FlexDeploy
...