Configuring CICD Process Using Azure DevOps
  • 24 Oct 2022
  • 6 Minutes to read
  • Dark

Configuring CICD Process Using Azure DevOps

  • Dark

Article summary


The Decisions platform is able to leverage Azure DevOps by using a Decisions Repository server to automate Project checkouts into other Decisions environments. The following document provides an example of how to integrate an Azure DevOps Pipeline with a Decisions Repository server.

  • Azure DevOps account. To learn more, see
  • Two Decisions environments, at least one being Non-production, must be already configured
  • A Decisions Repository previously configured
  • The Powershell module must be installed on the Decisions Repository. To learn how to install a module, see Installing Modules
  • A GitHub account to create a repository.
  • An Azure DevOps organization. To learn more, visit Microsoft's documentation for Sign up for Azure Pipelines.

The following process containing the automated checkout process will need to be imported into the Decisions server that is the target of the release pipeline:

   Automated Checkout Process-04062020-012148 (1) (1).zip  


In this example, a Flow will be run in the Decisions Repository server after each Check-in that calls the Azure DevOps Release Pipeline via Powershell and runs a POST call from the release pipeline that triggers a Checkout from the Decisions Repository to other Decisions environments.

In order to set up a release pipeline in Azure DevOps, an artifact needs to be generated. This will also create the BuidId value that will be used later as a reference to the release pipeline from the Powershell script.

When triggering the release pipeline API, an artifact BuildId is a required value.
  1. Navigate to the Repos > Files tab in Azure DevOps and select the Import repository action.
  2. In the Import a Git repository window, paste the Clone URL from the GitHub repository in the Clone URL field. Enter a Name and select Import.
    For more information on the Clone URL, see GitHub Clone URL.

    Configuring CICD Process Using Azure DevOps (7).png

  3. Configure a build pipeline by clicking Set up build in the repository and configure a Starter Pipeline.
    Running the build pipeline will generate the BuildId needed for the PowerShell script. 

    Configuring CICD Process Using Azure DevOps (28).png

  4. Select Save and runto generate an artifact with a BuildId. The BuildId value will be present in the URL.

    Configuring CICD Process Using Azure DevOps (29).pngConfiguring CICD Process Using Azure DevOps (30).png

  5. Create a service connection. by opening the Service Connections page in Azure DevOps from the Project Settings page, selecting New service connection, and setting the type of service connection as Generic. Fill in the necessary parameters for the service connection. 

    In this example, this will be the integration link for the main Flow of the checkout process. This can be configured using the example URL below.

    Server URL:

    Service Connection Name: name for the service Connection.

    Configuring CICD Process Using Azure DevOps (11).png

  6. Create a Release Pipeline; select the Pipelines > Releases tab and Empty job as the template.Configuring CICD Process Using Azure DevOps (15).png
  7. On the Release Pipeline, take note of the definitionid in the URL, as this will be used in the Powershell script to refer to this release pipeline.Configuring CICD Process Using Azure DevOps (14).png
  8. Select Add an Artifact and specify the Git repository name as the ‘Source(Build Pipeline)’ and a recognizable name for the Source Alias, then select Add.Configuring CICD Process Using Azure DevOps (18).png
  9. Navigate to Tasks > Stage 1. Click the ellipses and select Add an agentless job.Configuring CICD Process Using Azure DevOps (31).png
  10. Select the sign on the agentless job and click Add under the task Invoke REST API.
    Invoke REST API will invoke the REST call that calls the checkout process in target environments.
    Configuring CICD Process Using Azure DevOps (32).png
  11. Configure the POST call as follows. Once configured, click Save.
    Connection type: Required. Select Generic
    Generic service connection: Required. Select Generic service connection that has already created
    Method: Required. The HTTP method to be selected in POST
    Headers: Optional.
    Body: { "outputtype": "Json", "parentFolderId": "Destination Folder ID for Items without root folders(Default IDis for the MyApps folder)", "moduleName": "ProjectName flow input", "branchName": "BranchName flow input", "Username": "Repository User Name here", "UserPassword": "Repository Password here", "RevisionId":"$(RevisionId)" }
  12. Add a variable for RevisionID, as this value will be passed dynamically from the Powershell script into the release pipeline and be used in the POST call. This variable should be configured with the following credentials: "RevisionId: dummy".
  13. Generate a Personal Access Token (PAT).  
    To learn how to generate a PAT, visit the Azure DevOps article Use personal access tokens. The PAT will be used by the PowerShell script to authenticate into Azure DevOps.

Configure Decisions Repository to Trigger the Release Pipeline

After Azure DevOps is configured, move on to configuring the Decisions Repository.

  1. Create a Powershell Script. The script is used to call the Azure DevOps Release Pipeline and also Passes Revision ID dynamically to the pipeline.
    To learn more on Powershell scripts in Decisions, see Powershell Module Basics.
  2. Once in the script editor, add the following. Select OK to create the script.




    $AzureDevOpsPAT = "AzureDevOpsPersonalAccessToken"
    $AzureDevOpsAuthenicationHeader = @{Authorization = 'Basic ' + [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$($AzureDevOpsPAT)")) }
    $body = "{
     `"definitionId`": DefinitionID, 
     `"description`": `"Creating Decisions Release`",
     `"artifacts`": [   {
       `"alias`": `"ArtifactAlias`",
       `"instanceReference`": {
        `"id`": `"BuildID`",
        `"name`": null
       }  }  ],
     `"isDraft`": false,
     `"reason`": `"none`",
      `"variables`": {
      `"RevisionId`": {
      `"value`": `"$($revisionid)`"
      }  },
     `"manualEnvironments`": null }"
    Invoke-RestMethod -Uri $releaseUrl -Headers $AzureDevOpsAuthenicationHeader -Method post -Body $body -ContentType "application/json"

Using the Script Step

  1. In the Repository environment, navigate to System > Administration > Repository Action Flow.
  2. Click FLOW and select Create After Checkin Flow from the Global Action Bar. Provide a Name and click CREATE.
  3. From the Flow Designer, add a Script Name step from the INTEGRATION > POWERSHELL > SCRIPT PROJECT NAME category of the Toolbox tab. Drag the step into the Flow workspace.
    Notice the inputs match the Script input as stated above. Running this Flow in the Debugger will trigger the release pipeline. Checking in Flows to the repository will also trigger the release pipeline.

    Configuring CICD Process Using Azure DevOps (33).png

Proposed Method For Version Control When Integrating With Azure DevOps


  • Import the following project on the Repository:

   Repository Checkin  

Dev will be pointed at Trunk on the repository at all times unless a bug fix is needed
  1. Once the Project is ready to be pushed to the target environment, push the Project to the Repository by navigating to Designer Repository and selecting Send Changes for Project.
    This will trigger the ‘After Check In Flow’ that calls the Azure DevOps Pipeline and sends the trunk version of the project to the environment specified in the pipeline.

    Configuring CICD Process Using Azure DevOps (24).png

  2. When a new version of the Project is ready to be implemented, login to the Repository and locate the Project.
  3. Right-click Trunk and select the Create Branch action.
    1. Name the Branch in accordance with a Branch naming strategy. 
    2. On the revision in the Branch being pushed to the target environment, select Mark For Release
      This action will send the branchName and revision id to the Azure DevOps pipeline where it can then be approved to be pushed to the target environment. Rollbacks can be done using the redeploy action available on releases in the Azure DevOps pipeline.

If a bug fix is needed:

  1. Ensure that development is stopped on Dev
  2. Push the most recent version of the Project on Dev to the Trunk Branch in the Repository. This ensures any work on Dev is not lost
  3. Navigate to System > Designers > Repository in the Dev environment, locate the Project, and select the Change Branch.
  4. Select the branch that represents the release candidate at issue and follow the Change Branch prompts to import this version of the project onto Dev. Make the necessary bugfix then send changes to the Repository using the Send Changes for Project action.

  5. Navigate to System > Designers > Repository in the Dev environment and use the Change Branch to change the Branch back to Trunk

  6. Navigate to System > Designers > Designer Repository, locate the updated Branch, and create a new branch from it via the Create Branch action.

  7. Right-click the most recent revision and select Mark For Release to send the branchName and the selected revision id to the Azure DevOps pipeline where it can then be approved to be pushed to the target environment.

Was this article helpful?