FlexDeploy integration with Azure DevOps Release Pipeline

Objective

The goal of the tutorial is to demonstrate on how to integrate Azure DevOps Release pipeline through FlexDeploy.

• FlexDeploy is going to download codebase from Git repo and upload selective files(.xml extension) to Azure DevOps Artifact repo as package,

• FlexDeploy will initiate Azure DevOps Release pipeline execution.

• As part of the execution, the package files(from Artifact repo) shall be copied to Blob Container under Azure Storage account.

• The Storage account name and Blob Container name shall be passed by FlexDeploy dynamically during Release creation and Release environment stage execution respectively.

This tutorial is to demonstrate the creation of releases using the createRelease operation and the subsequent initiation of these releases environment executions using the updateRelEnvStatus operation.

We will walk through each of the FlexDeploy features that will be created and configured to accomplish this goal. By following the steps below, we will be able to create the release and trigger the release stage execution in a very short amount of time.

Checklist

Azure DevOps Release pipeline configurations

1. Azure Storage Account is going to be static in our case, hence this will be passed during Release creation through varPassedWhileReleaseTrigger. Check the Scope for this variable is Release.

2. Where the target Blob container is different env-wise. Hence we are going to pass the container names through varPassedWhileStageTrigger for each env stage execution. Check the Scope for this variable is Dev, QA & Prod, since they are env-specific.

Settable at release time property is checked since we want to pass the values through FlexDeploy runtime.

Open

Navigate inside the Release pipeline Stages, for each environment we need to select the Pre-deployment conditions and set the trigger as Manual only. This will ensure that this stages has to be explicitly triggered ( FlexDeploy in our case) to initiate the deployment. If this is not selected once the Release is created the env-wise deployment shall happen automatically.

Open

We have used Azure Blob File Copy operation to copy the files inside Storage Account Blob Container.

Both Storage Account Name & Blob Container name we are going to pass dynamically.

1. We are passing variable varPassedWhileReleaseTrigger against Azure Storage Account. We have already mentioned in last to last step regarding this variable.

2. We are passing variable varPassedWhileStageTrigger against Container name for each env stage execution. Both values needs to be passed from FlexDeploy.

Note : This is just for showcasing the capability of passing dynamic variables, you can always have the values static in case the are not changing.

Configure Cloud Account

First, an Azure account needs to be configured under Integrations. FlexDeploy will

1. Select Integrations from the Menu.

2. Navigate to the Cloud tab from the left-hand pane.

3. Create a new Cloud account of the provider type “AzureDevOps” with the “+ Create” button.

It should have a Organization URL and Personal Access Token configured in it.

1. Azure DevOps Access Token is a password (Personal Access Token) field and hence needs to be kept hidden. To update the same click on the pencil icon as shown below

2. Update the Personal Access Token value under Secret Text. This is to make sure no one else can retrieve the password

Build Workflow

Technical steps involved:

• FlexDeploy shall download the code from scm, create the artifact object with selective files(.xml) and upload the package in Azure DevOps Artifact repository.

1. Navigate to the Workflows tab

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

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

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

1. Navigate through the plugin operations and find the desired one.

2. In our workflow execution, 3 plugin operations being used to achieve our goal.

Below given is a logical explanation of build workflow to publish the artifacts generated to Azure DevOps Artifacts Source.

Step: 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.

Step: Copy the files generated to Artifacts Directory

.xml -extension files(if applicable/present) will be moved to FlexDeploy Artifact directory. *.xml is added under File Filter to selective move files with xml extension only. This will create FlexDeploy artifact object with the files.

Copy File operation relevant inputs:

Step: Publish the Artifacts to Azure DevOps Artifacts Source

Below given are the Azure plugin (publishArtifacts operation) configurations.

Publish Artifacts operation relevant Inputs

Other input parameters also can be passed/updated as needed.

Build Workflow Properties

We'll start by creating a Workflow Property for the Feed Name, Package Name and Project Name.

1. Go back to the Main tab of the Workflow.

2. Under Workflow Properties, use Add option to add the properties.

3. From the Add menu, we can add an existing property, or create a new one. Select New Property

4. Properties must each have a unique code, give a meaningful code for the new property.

5. A property Display Name does not have to be unique and can contain spaces. This is the name that will be displayed on the Project/Target property association screen.

6. Select the property scope, this defines where the property will be configured. We're using Project because this property can be overridden at project level.

n.b. The properties scope can be Target as well. In case any property value is environment specific (e.g. Project Name is different for each environment), then the scope should be set as Target. This will changes based on requirement.

Click on save and Activate the workflow.

Deploy Workflow

Technical steps involved:

• FlexDeploy shall create the Azure DevOps Release pipeline instance. The new Release instance will be created from the pipeline first/lowest pipeline environment only (Dev in this case). The same Release pipeline shall be leveraged to deploy across all environments.

• It can optionally pass variable/properties details as well.

• FlexDeploy till now has just created the Release instance. It will capture Azure DevOps Environment Id & other relevant details from create Release step.

• Next FlexDeploy will initiate the Release stage deployment env-wise.

• It will also pass required environment to initiate deployment along with env-specific variables.

• Release pipeline can use the package uploaded by Build workflow in Azure DevOps Artifact repo.

• FlexDeploy can also optionally check(preferably) the completion status of Release execution env-wise.

Similar to Build Workflow, following the same steps we are creating the deploy workflow. The Workflow Group and Subgroup define the folder hierarchy. Once the workflow is created, it should appear as given below. No constraint on workflow or folder naming convention.

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

Let’s try to understand the if block which is applicable only for the environment Dev (first/lowest env inside pipeline). Below given is the logical flow.

createRelease operation returns the Release Id and Environment Details specific to the newly created Release. Environment Details basically return unique ids for each configured environment, against the created Release instance.

One important thing to understand here is, for each new Release in Azure DevOps, the generated EnvirontmentId is unique even through the Target Environments(e.g. Dev, SIT, Prod) are same. Above workflow creates the Release in Azure DevOps and also returns the created Release Id and corresponding Environment Details as Workflow Output variables.

Let’s try to understand the else block which is applicable for all other higher environments.

Another key thing to understand here is - Release Id and corresponding Environment Details are created only during Dev environment execution. However same details are need for all other environments as well. That's why we have 2 workflow input parameters to propagate the same. And this will be the job of pipeline to capture the Workflow Output variable from Dev Environment and pass those values as workflow input to all other environments.

Below given is the logical flow for else block.

Step: If pipeline environment is ‘Dev’

Validates if the Deploy is triggered on Dev environment. If Environment is Dev, proceed with create Release.

Step: Create Release instance for Azure DevOps Release pipeline( If block)

Below given are the Azure plugin (createRelease operation) configurations.

As can be observed from highlighted Output, that the RELEASE_ID & ENV_DETAILS are captured from plugin Output.

createRelease Operation relevant Input details

Step: Assign Release Id captured during createRelease operation (else block):

Substring is to remove the quote sign( ' ) around the Release Id.

Step: Assign Environment Details captured during createRelease operation (else block):

Step: Parse Environment specific Id

Based on the current Environment Code, this method will capture the Release stage Environment ID.

n.b. It’s essential that he Azure DevOps environment name is exactly same as the Environment Name configured in FlexDeploy. Else below step wont work properly.

Parse Json Inputs:

Step: Trigger deployment of Azure DevOps Release based on environment

Based on the given Release ID, Release Environment ID, Project Name this method will trigger the respective environment stage that is set as 'Manual'.

In case the status of Environment specific Release deployment status Boolean flag is checked, the flow shall check for completion status for a pre-defined number of times at regular interval.

updateRelease operation relevant Inputs:

Deploy Workflow Properties

We'll start by creating a Workflow Property for the Feed Name, Package Name and Project Name.

1. Go back to the Main tab of the Workflow

2. Under Workflow Properties, choose open the Add men.

3. From the Add menu, we can add an existing property, or create a new one. Select New Property

4. Properties must each have a unique code, give a meaningful code for the new property

5. A property display name does not have to be unique and can contain spaces. This is the name that will be displayed on the Target screen

6. Select the property scope, this defines where the property will be configured. We're using Project because this property can be overridden at project level and Target to capture environment level properties.

Note: It may appear interesting that we are using 2 Target variables (CONFIG_PORT & CONTAINER_NAME) however we haven’t used them in the workflow. We wanted to pass these details dynamically to Azure DevOps Release based on env-specific value configured under Topology-->Target Properties. Further details can be found under Topology and Project Properties .

Topology

For detailed steps on how to configure the topology and target properties, please refer to Target Groups

Target Properties

Selecting the DEV environment mapped to the Target Group will display the configurable properties/Endpoint and allows to the configure the properties.

Provide the value for AzureDevOpsCloudAccount, AzureCLIPath (optional if set in classPath), Azure DevOps API Version (optional default value is 7.0), Scope of the Feed (optional default value is project used in publish artifacts operation), Number of Iterations (optional, default value is 6), and, Interval Duration (optional default value is 30 sec) and map the localhost as Endpoint as shown below. Also, the target level properties that we created at the workflow level will be displayed here along with other properties.

Also Container Name is set here which is a env specific value.

Target Properties details

Create the Azure DevOps Create Release Flow Project using Blank Project

The assumption is that you have FlexDeploy installed and ready for use. When logged into the FlexDeploy, you will see the Home page. Click on the + icon on the top and click “Create Project” to create a new project.

The screen displays the list of blueprints supported by the FlexDeploy. Select a Blank project from the list or you can search for the blueprint in the search filter present in the top.

General Configuration

Scroll through this guide to fill in the project information.

Project Info

Project configuration

We can see the Folder hierarchy on the top of the project and the project configuration as below

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. Click on Save.

Project Properties details

Build Execution

1. Navigate to Execution tab and click on Execute to submit the Build Request form.

2. The Build Request Form will appear and we need to select the environment.

3. Select main as branch name.

4. Submit the request, this will initiate the AzDevOpsBuildFlow workflow.

Upon submission, the build workflow is initiated and the workflow steps are executed on the AzureDevOps target group in the DEV environment, utilizing the Localhost endpoint to generate the Artifacts and publishArtifacts operation will publish the generated artifacts to the Azure DevOps Artifacts Source. Upon completion of the workflow, the execution status will be successful.

Navigate to steps tab in order to view the workflow steps. Click on the link to view the plugin logs.

Deploy Execution

Navigate to back to the Execution tab and click on icon shown as below to submit the Deploy Request form.

The Deploy Request Form will appear and we need to:

1. Select the Project Version. The form will default to the latest Project Version but the dropdown will contain all previously create Project Versions.

2. Select the Environment that the deployment will be executed in.

3. Select the Deploy Instance, which will be defaulted from the Project configuration.  Deployments can happen on multiple instances.

4. Submit the request, which will initiate the Deploy Config Configurations workflow.

Upon submission, the deploy workflow is initiated and the workflow steps are executed on the Azure DevOps instance in the Dev environment, utilizing the Localhost endpoint. Upon completion of the workflow, the execution status will be successful.

Post deployment - Execution on Azure DevOps

Post Deployment success might take some time to deploy the package with provided version. In case of failure we can easily debug the issue from the log or navigate to the Web URL which is returned as output variable FDAZ_DevOps_OUT_REL_ENV_WEB_URL in Azure DevOps Platform.

Azure DevOps Release Deployment

Congratulations! You have successfully completed the Azure DevOps Create Release and Update Release Environment Status tutorial.

Now that you have configured the project and executed the Azure DevOps Create Release Flow. It is extremely easy to replicate the same steps for another Azure DevOps Create Release Flow Project using Blank Project. 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.