Page Comparison

Image Removed

Image Added

It should have a Client ID, Client Key, Tenant Id, and Subscription Id configured in it. The Client ID must have relevant access in the target WebApp to deploy code and make other associated changes(Application Setting update etc).

Image Removed

Image Added

 Client Key is a password field and hence needs to be kept hidden. To update the same click on the pencil icon as shown below

1. Update the Client Key value under Secret Text. This is to make sure no one else can retrieve the password

Image Removed

Image Added

Git repository structure

The Git repository should contain the codebase. Alongside it can also contain any Application Setting and Connection String-related attributes in respective files(any naming convention allowed). These files are not mandatory, however, in case someone has any Application Setting and Connection String property to update this is recommended. Please review the Application Setting and Connection String property update for a detailed explanation.

The Sample Git repository structure is given below.

Build and Deploy Workflows

Navigate to the Workflows tab and create a workflow using the “+”(Click to create new Workflow) button as highlighted below.

Image Removed

Image Added

Next, create one Build and Deploy workflow as shown below. The workflow Type field defines the type of workflow.

Build Workflow

1. Navigate to the Workflows

2. Select the “+” button from the left-hand pane to create a new workflow with type as Build.

Image Removed

Image Added

Deploy Workflow

1. navigate to the Workflows

2. Select the “+” button from the left-hand pane to create a new workflow with type as Deploy.

Image Removed

Image Added

The Workflow Group and Subgroup define the folder hierarchy. Once both workflows are created it should look like the below. No constraint on workflow or folder naming convention.

Image Removed

Image Added

The steps of the workflow execution can be configured through the Workflow Definition section.

Image Removed

Image Added

Below given is a sample build workflow to build a Java executable(war file) and create an artifact from it.

Step-i: Clone Git Repository

This step will clone the Git repository codebase into the project execution working directory. The Git URL will be retrieved from Source Control configured under Project Configuration.

Below given is the Git code structure and corresponding exported codebase during execution as a result of the above step.

Git Codebase

Exported Codebase

Step ii: Execute Maven Build

The below step will execute the maven build with the project pom.xml and will create a Java executable(.war) file inside the target directory.

From below capture of project export we can find the pom.xml is present under App-service folder. The same needs to be mentioned under Project Location property for the plugin to find the pom.xml

note: Each application will have separate directory structure hence the all paths need to be modified accordingly.

Step iii: Copy the properties file to the intermediate dir

Application Setting and Connection String json files(if applicable/present) will be moved to the intermediate directory. An intermediate directory can have any name, in this case, we are using the artifactsObjects folder inside the temp directory. File names are mentioned under File Filter with ‘##’ separated(as advised in the description). Application Setting and Connection String values can also be passed as input to deploy workflow. Application Setting and Connection String files are optional, please review the Application Setting and Connection String property update for a detailed explanation.

Step-iv: Create an archive of the executable in the intermediate dir

Per the Azure Web App deployment requirement, we have created an archive with the java executable inside it.

Image Removed

Image Added

note: Each application will have separate directory structure hence the all paths need to be modified accordingly.

If we look inside the generated deploy.zip(during execution), it contains the war file only. Basically, it contains the executable files that need to be copied to the Azure WebApp backend. Azure WebApp treats this as an executable package and runs it.

Note: the war file(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.

Step-v: Save all from the intermediate dir as Artifact

Post execution of the above steps the intermediate directory(artifactObjects) should contain files as shown below.

These objects are required as part of the deployment flow. Hence we create an archive(artifacts.zip) with them inside the Artifacts directory. We also enable Produces Artifacts checkbox to save the zip file as an artifact.

As part of the above step, all files inside the artifactObjects folder are archived to create an artifacts.zip which will be saved as an artifact for future reference from the Deployment workflow.

Note: The directory name/artifact name can be anything. The deployment workflow expects only one .zip file inside the artifact containing the executable(.war file in this case). It will search for a .zip extension and treat it as a package archive for deployment.

Note: the deployWebApp operation(Azure plugin) will search for the Application Setting and Connection String file name provided as part of Project properties. Irrespective of folder structure it will find the file. In case more than one file exists with the same name, flow shall fail.

Below given is a sample deployment workflow to deploy the archive to Azure Web App.

This step first updates the Application Setting/Connection String values from the files present in the artifact(optional). Instead of using Application Setting and Connection String files, one can directly provide the values as part of plugin input.

In such case, we can create input variables on deployment workflow like the given below and pass them as deployWebApp operation input argument. This is optional and any other way to pass the arguments(e.g. hardcoded value) is also acceptable.

First, navigate to the Workflow Definition tab and click on the Create/View Inputs button as shown below.

Create two input variables, one each for Application Setting and Connection String as shown below.

The input arguments are then mapped to the input properties of the deployWebApp operation as shown below. The plugin will take the input values and process them accordingly.

The deployWebApp operation returns four output variables. To capture them and use them for further processing/evaluation, one can create four variables and map them against the output parameters of the deployWebApp operation. Return As Output drop down option should be set as Yes.

1. First, navigate to the Workflow Definition tab and click on the Variables button

2. Next use Create option to add four output variables.

Map the variables against the output of the deployWebApp operation to capture the responses.

Project configuration

Navigate to the Project tab and create a Project with a logical name(JavaAzureWebApp in this case)

Configure the Build and Deploy workflow that has been created in previous steps as shown below.

Anchor
Source_Control Source_Control

Source Control

Configure the Source SCM repository under Source Control as shown below.

1. To configure Project specific Source Control one first need to navigate to the Project Configuration tab.

2. Next, expand the SOURCE CONTROL option from the left-hand pane.

3. Select SOURCES for configuring the Source Repository

4. Select the appropriate Source Control Type

5. Configure Source Repository.

For detailed steps of Source Control configuration please refer to Configure Source Control in FlexDeploy

Project Properties

1. To configure Project specific settings one can navigate to the Project Configuration tab as shown above.

2. Next, select the PROPERTIES option from the left-hand pane.

3. To deploy a WebApp to Azure Web App, the first two mandatory properties are the WebApp App Name and Resource Group Name. These need to be configured under Project properties.

4. Remote Build: This flag is applicable in case we want to upload the code to the Azure Web App backend and build it there itself (e.g.: .NET/Node.js). We are creating the Java executable(war) file explicitly as part of the build workflow, hence this checkbox can be left unchecked for this flow.

5. Under Project properties, one also needs to provide the Application Setting/Connection String file names(if applicable).

6. Show deployment log: Once deployment is completed, in case someone wants to verify the execution steps, they need to check the below checkbox under Project properties.

   In this case, the plugin will internally retrieve the deployment Id and will fetch the Deployment log(if available), and return the same as an Output variable.

   This is applicable only for Code archive deployment(not for docker image deployment.)

Anchor
Application_Setting Application_Setting

Application Setting and Connection String property update

These Application Setting/Connection String properties are non-mandatory and can be directly provided as plugin Input as well. Or even may not be passed at all. However this is the recommended way and the files should exist in the working directory(TEMP) during execution(folder hierarchy is not required, the plugin will search the file based on the file name).

Although only one Application Setting and one Connection String file are allowed per project.

Application Setting and Connection String are two separate entities so whichever files exist, the same will be considered during deployment.

First, let’s review the sample Application Setting file (same structure as the local.settings.json file). In our scenario, there are two dynamic values that need to be propagated to WebApp App Application Setting.

One of them DYNAMIC_TESTKEY1: is project-specific and env agnostic

DYNAMIC_ENV_TESTKEYVAL2: another one however changes env-wise

Both are already added to the AppSettings.json file present in Git Repository.

Both properties need to be configured in workflow Properties with relevant Property Scope.

1. To pass the value for DYNAMIC_TESTKEY1(Project specific) one first needs to navigate to the Configuration tab

2. Next, select the PROPERTIES option from the left-hand pane and provide the proper value against the property.

For Environment property, the same needs to be added against Environment-Target Group properties.

1. First, navigate to the Topology.

2. Next, navigate to the Environment-Target Group properties section for the intended Target.

3. Next, select the PROPERTIES tab and provide the value for DYNAMIC_ENV_TESTKEYVAL2(environment specific) as shown below.

Application Setting/Connection String can also be passed as an input argument to the deployWebApp operation. The sample is shown as given below.

Please refer to this link for the input structure of Application Setting and Connection String both when passed as a file or as input parameter - Application Setting/Connection String file and input content acceptable structure

In case both the Application Setting file and Application Setting input argument are passed, a consolidated list of properties will be considered while updating WebApp App. In case the same attribute is used both in the file and input, the value provided as part of the input will take precedence. The same applies to Connection String as well.

Also, it’s not mandatory to have dynamic values. One can always pass static hard-coded value if needed (although not recommended).

Application Setting and Connection String values will be updated against the WebApp 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

• 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

Selecting the GREEN circle for DEV will display the configurable properties/Endpoint and allows for the configuration of

Below given are the environment-specific values which need to be updated.

Also in case, we are adding any environment-specific properties for Application Setting/Connection String(as mentioned in the previous step), those values should also be updated.

The Azure Could account needs to be set here from the drop-down. It will show all Cloud Accounts configured under Topology, which we have already mentioned earlier.

Anchor
DeploytoSlot DeploytoSlot

Deploy to Slot

Azure Web App default slot is production. However, one can configure multiple slots and deploy web application on those slots inside WebApp App. WebApp 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.

executeWebAppAppSlotSwap operation can be used to perform the slot swap.

Build Execution

For detailed steps on how to initiate Build Azure WebApp, review artifacts, and ultimately deploy to Azure Web App please refer to Build and deploy execution through FlexDeploy

Congratulations! You have successfully completed the Java Application deployment to the Azure Web App tutorial.

Now that you have configured FlexDeploy for one Azure Web App, it is extremely easy to replicate the same for other Azure Web App. Simply use the Copy Project feature and a new project will be created with all of the configuration completed already. You just need to make the necessary configuration changes.