The Complete Guide to UiPath CI CD with Azure DevOps

Satish Prasad
37 Min Read

Step by step working example to setup CI/CD pipeline for UiPath using Github and Azure DevOps

DevOps is a mindset, a way of working for an organization so that new features reach to the users as quickly as possible and smoothly too.

There have been discussions regarding how continuous integration and deployment concepts can be applied to the RPA development cycle.

Topics covered in this article –

  • What is CI/CD in the context of RPA (Focus on UiPath)
  • Key Concepts in Azure Pipelines
  • Build the first pipeline to package UiPath project
  • Different ways of UiPath CI/CD pipeline creation using Extension or Powershell
  • Required Service Connection configuration
  • Configure self-hosted agent
  • Complete working example.
Let’s get started! 
What is RPA all about

Are you looking for DevOps integration using Jenkins

How to Create a Pipeline for UiPath Using Jenkins, Step by step guide, Fully working example.

What is a CI/CD pipeline?

A CI/CD pipeline workflow usually consists of the following discrete steps:

  • Phase 1: Commit – When developers complete a change, they commit the change to the repository.
  • Phase 2: Build- Source code from the repository is integrated into a build.
  • Phase 3: Automate tests- Automated tests are run against the build. Test automation is an essential element of any CI/CD pipeline.
  • Phase 4: Deploy- The built version is delivered to production.
What is a CI/CD pipeline
What is a CI/CD pipeline

Continuous Integration (CI)

Continuous integration (CI) is the practice used by development teams to simplify the testing and building of code. CI helps to catch bugs or problems early in the development cycle, which makes them easier and faster to fix. Automated tests and builds are run as part of the CI process.

The process can run on a set schedule, whenever code is pushed, or both. Items known as artefacts are produced from CI systems. They’re used by the continuous delivery release pipelines to drive automatic deployments.

Continuous Delivery (CD)

Continuous delivery (CD) is a process by which code is built, tested, and deployed to one or more test and production stages. Deploying and testing in multiple stages helps drive quality. 

Continuous integration systems produce deployable artifacts which are used in CD to release new versions and fixes to existing systems. This process ensures that errors are caught often and early.

CI/CD in Context of RPA Tool UiPath

Although many organizations have started implementing a Digital Workforce into their business operations – only a few are fully in control of their RPA bots.

Very few COE has already implemented the CI/CD (Continuous Integration, Continuous Delivery) pipeline that allows you to automate your robot delivery process.

A typical pipeline for UiPath can be –

  1. The pipeline will initiate the build from your version control system.
  2. The pipeline will also perform the creation of various assets, config replacement, creating initial folders etc.
  3. The pipelines will publish the package to Orchestrator.
  4. It can further include workflow analyser to code review, approval workflow, integration with ITIL tools such as(service now) for change board approvals.
  5. It can be further improved to Run test cases from Orchestrator.

 

 

CI CD Pipeline for UiPath
UiPath Azure Devops Integration,CI CD Pipeline for UiPath

Why should You use Azure Pipelines?

  1. An azure pipeline is free if you want to implement it for public projects. (You can run 30 Hours free pipeline even if you have a private project)
  2. Its helps to implement CI and CD pipelines to ensure best code quality and work with any language or platform you wish to use.
  3. You can use Azure Pipelines with most application types, such as Java, JavaScript, Node.js, Python, .NET, C++, Go, PHP
  4. Build can be used on Windows, Linux, or Mac machines. (However, for UiPath build we need only Window-based Agents.)
  5. Azure Pipelines deploy your code to multiple targets. Targets include container registries, virtual machines, Azure services, or any on-premises or cloud target. You can configure it as per your organization need.

Key Concepts in Azure Pipelines

Before I talk about building an azure pipeline for Build, Test and Deploy. You need to understand the basic building blocks of the Pipeline. Such as-

  • Agents
  • Conditions
  • Expressions
  • Jobs
  • Stages
  • Tasks

Let’s quickly discuss the key concepts used in the azure pipeline.

  • An Agent is computing infrastructure with installed agent software that runs one job at a time. You can treat the agent as executor which actually performs the jobs as instructed by the pipeline stages. Your agent must have the capability to perform a certain action. In our example, UiPath must be installed on an agent to perform build/test.
  • A trigger tells a Pipeline to run. In the above example, It’s the setup that tells when the pipeline needs to be run. You can configure a pipeline to run when you publish your UiPath Projects to Git or Repo you are using. This can be also configured to run at scheduled times or upon completion of another build.
  • A Stage is a logical grouping of Jobs in the pipeline and each stage can have one or more jobs that run on Further your job can contain one or more step(task/script)
  • A Step can be a task or script and is the smallest building block of a pipeline. For example, you are creating a pipeline which consists of build and test steps both. Your step can be either a ‘task’ [Custom Code] Or Script written in PowerShell or Shell Script. For example, there is a task, that task has got five different stages, and each stage has got some steps. All the steps in phase one have to be completed, to mark the latter stage to be complete. 

Using Azure DevOps

As Discussed above, Azure Pipelines supports continuous integration (CI) and continuous delivery (CD) to constantly and consistently test and build your code and ship it to any target.

  • You accomplish this by defining a pipeline.
  • You define pipelines using the YAML syntax or through the user interface (Classic).
  • You can also use the YAML templates provided. Make sure to update variables as per your need.

How to implement a CICD pipeline using Azure DevOps Pipelines?

Alright ! So far we have discussed details about the Azure DevOps platform, Let’s take a basic example of creating a pipeline to create a NuGet package.

Once we understand the work we will move to the next example of the full-fledge project working.

Let’s jump in!

Step 1: Prerequisites - Azure DevOps

 

  • Before you use continuous integration and continuous delivery practices for your applications, you must have your project source code in a version control system. Azure pipelines can integrate with GitHub, TFVC, Bitbucket Cloud, Azure Repos Git and SVN…
  • An Azure DevOps organization. If you don’t have one, you can create one for free. (An Azure DevOps organization is different from your GitHub organization. Give them the same name if you want alignment between them.)
  • If your team already has one, then make sure you’re an administrator of the Azure DevOps project that you want to use.
  • Use the following URL to sign in to your organization at any time: https://dev.azure.com/{yourorganization}
  • You need to have Windows-Based Build Agent as now its only Support Windows Agent. You can create Pool of Agents or Simply use your Laptop as Agent for learning purpose.

Step 2 : How to Set Up Azure DevOps & UiPath Extension for Azure DevOps [One Time Setup]

 

Implement continuous integration and continuous delivery (CI/CD) for the app and platform of your choice require set-up to be done before writing your first pipeline.

  • Sign up for an Azure DevOps organization – if you have existing Microsoft account, all you need to do is click on “Start free” to get your account created.
  • It will ask you to login using Microsoft account, you can use your personal account as well. Alternatively, you can choose “Start Free with GitHub”.
  • Default Organization will be created with your email as yourorganization. Which can be accessed later using https://dev.azure.com/{yourorganization}
  • You should be able to create as many as Azure DevOps organization you need by simply giving the Organization Name and hosting location.
  • The next step is creating a project by specifying the Project Name, Description, Version Control System (Such as Git) and the most important is Visibility.
  • If you use your project type as public projects, Azure Pipelines is free. If you use private projects, you can run up to 1,800 minutes (30 hours) of pipeline jobs for free every month.
  • Once Project is created you should be able to Create your first Pipeline using step by step Wizard.
  • You can connect your GitHub Account to integrate the projects you have published in a git repo.
  • You also need to provide Approve & Install Azure Pipelines so that required permissions are granted on the repo.

You can read more details here – [Signup for Azure Pipeline]

 

An AzureDevOps extension is also available that allows you to build and deploy UiPath automation processes, as well as run UiPath automated test cases. For using the extension you need to install it on Azure by getting it from the visual studio marketplace.(Check uipath.vsts-uipath-package)

Next, we need to install the UiPath Integration extension to your Azure DevOps organization. The UiPath Integration for Azure DevOps comes with a pack of pre-created tasks that allow you to build and deploy UiPath automation processes

It provides following built-in capability-

  • The UiPathPack task enables you to package an existing UiPath project into a NuGet package.
  • The UiPathDeploy task lets you deploy a UiPath NuGet package onto UiPath Orchestrator.
  • The UiPathTest task runs an existing test set on Orchestrator, or packages, deploys and runs test cases as a transient test set in one go, by specifying the path to a UiPath test project.
  • The UiPathAssets enables you to deploy, update or delete assets on an Orchestrator instance. In order to deploy assets, you must describe them in a CSV file encoded in UTF-8.
  • The UiPathInstallPlatform has a prepackaged tool that all the other UiPath tasks are using. The task is optional, but it should be used as it reduces the time to execute the other tasks. The task is required when build agents do not have access to https://www.myget.org/F/uipath-dev/. The task should be executed before all other tasks in the extension.
  • The UiPathRunJob task starts an already deployed process on an Orchestrator instance. The processes this task refers to are found in Automations->Processes on newer versions of Orchestrator and directly on the Processes tab on older versions of Orchestrator.

For the UiPathDeploy and UiPathTest tasks, you will also need to first create a Service Connection. (Enable API Access and set required).

You can go to Project Settings ->Service Connections -> UiPath Orchestrator Connection and add the service connection details. For best practices, it’s required to create multiple tenants such as (DEV, UAT, and PROD) and configure them separately.

Read more details here – https://marketplace.visualstudio.com/items?itemName=uipath.vsts-uipath-package

Step 3: Create your first pipeline

At this point of post, I assume you already has setup the organization and projects in the Azure DevOps portal and now you are ready for creating your first pipeline.

  • Creating a pipeline is super easy if you understand the basic building blocks of Azure DevOps key concepts
  • All you need to do is add an “azure-pipelines.yml” file into your source code repository. if you are using the templates, or you can create it on Azure DevOps portal.
  • Let’s Create the first pipeline which will build the UiPath Project as. nupkg, we will look at the complete example later where I will build multiple stages to perform build test and deploy on orchestrator as well.

In the Azure DevOps project, click on “Pipelines” on the left menu of the page. Click on “New pipeline”. The following window will appear which will ask you to provide the details of your version control system.

Azure Pipeline Source Code Selection

You can select your GitHub repository; it will also ask you to provide access to manage code and other permission. You need to accept and install here. (If you are already connected you can select the project from the dropdown.)

Azure Pipeline Source Code Permissions Required

Once access for source code has been granted, you need to specify whether you are going to use.

    • Starter pipeline- Minimal setup
    • Use Existing Azure Pipeline YAML file.

If you have not created “azure-pipelines.yml” in your source code, you should select the Starter pipeline and edit the required details on the editor.

Azure Pipeline Starter pipeline

Copy the below code into the window(by replacing template) and save the file. All we are doing here is using the “UiPathRobot.exe file on the agent to pack the UiPath Project as. nupkg.

            trigger:
 - master
stages:
 - stage: Build
   displayName: Create build artifact
   jobs:
     - job: BuildArtifact
       pool: MYLAPTOP
       steps:
         - script: C:\Users\Satish\AppData\Local\UiPath\app-20.10.0-beta0149\UiRobot.exe pack $(Build.SourcesDirectory)\project.json -o $(Build.ArtifactStagingDirectory)\ -v 1.0.$(Build.BuildNumber)
           displayName: "Build the artifact"
         - publish: $(Build.ArtifactStagingDirectory)
            artifact: drop
        

The key point to note here is –

  1. We have used trigger as “master” that means any changes in the repo will trigger the pipeline. You can have multiple configurations.
  2. In the next line, Stages were specified with jobs and steps and the only step that is mentioned here is Running “UiPathRobot.exe pack” command.  the executable location will be different fro you and it depends on the installation. So update that accordingly.
  3. We have used the agent pool as “MYLAPTOP” as I have created agent on my laptop instead of using any VM or Docker, you can follow the configuration step to create Agent [See details in Configuration Section]

So now you are ready to Run the first pipeline.

If you don’t love GUI Steps, You can also use Azure CLI (command-line interface), See more here about creating a pipeline from the CLI(create-first-pipeline-cli ).

Once you run it you will see that “UiPathAzureDevOps.1.0.20201004.6.nupkg” gets published at the work location.

Azure Pipeline First Run result

Congratulations! You are done with your first pipeline to successfully build the  .nupkg.

But we are not done yet!

In the real project world, there will be a series of stages which includes various steps in different environment and approval and settings done by your organisation.

  1. You might need to perform an automated test as well after publishing in UAT or perform a smoke test to see if everything is good.
  2. You might need to include approval workflow where few tasks get completed and then it requires stage gates approval from the production support team.
  3. You might need change tickets workflow included in the pipeline to create change tickets with description and updating tickets once change gets completed.
  4. You might need to configure different assets in a different environment and inside different tenants of the orchestrator.

And so on…all that I want to convey here is creating a pipeline for UiPath depends on the practices being followed in your organisation.

In the next section,  I will talk about the different ways of creating a pipeline with the help of UiPath Extensions available for Azure DevOps and Via PowerShell Utility.

Azure DevOps CI/CD pipeline Templates for UiPath Projects and Library

Many developers have created a pipeline for UiPath and they have also published the template for UiPath Projects and library on GitHub. Which can be utilized to save your effort.

Here are few GitHub repo which can be used to build you pipelines from template.

You can clone the Templates files from the above repo to start it quickly.

UiPath Integration for Azure DevOps [Using UiPath PowerShell CLI]

In the above example, we have used the inline script to build the first pipeline. However, UiPath also provides support for PowerShell cmdlet for all the task you need to perform with UiPath Orchestrator.

This provides a better way in case you are not interested in using the extension and you can use PowerShell cmdlet inside your pipeline to perform the required task.

For example- You can get the UiPath AuthToken using the UiPath.Powershell and then use       Add-UiPathPackage to publish the package on orchestrator.

  1. Import-Module UiPath.Powershell

  2. $token = Get-UiPathAuthToken -ClientId $(uatClientId) -UserKey $(uatUserKey) -AccountName $(uatAccountName) -CloudDeployment ‘Production’ -TenantName $(uatTenantName)

  3. Add-UiPathPackage -PackageFile $(Pipeline.Workspace)\drop\project.1.0.$(Build.BuildNumber).nupkg -AuthToken $token

You can read more details of all the PowerShell Cmdlet here – [Orchestrator-PowerShell docs  ]

How to Set up Self-Hosted Build Agents in Azure DevOps

To run a build or release pipeline, a container is used in Azure DevOps to run the tasks in the pipeline. The containers are known as build agents and they vary in use case depending on the type of application being deployed.

In our case, we are using the UiPath Project so we need agents which are capable of building projects and running the UiPath test cases.

For sake of simplicity, you can say that running a UiPath CI/CD Pipeline we need an agent (Build Machine) which have UiPath already installed and configured.

For trying our hands out, we have set up a build agent on Windows 10.

You need to follow the following steps for setting Up Build agents –

  • Personal Access Token (PAT) is an authentication method used to authenticate your agent, so the first thing you need to do is navigate to the user profile and click Personal access tokens to access the PAT settings.
  • You need to provide PAT Name, Scopes which provides access associated with the token. You can select the full access or Custom defined as per your need.
  • It will provide you secure string, make sure to copy that save it in secure location this will be used in the next step to connect your agent with the organization.
  • Once you have PAT, Next step is to define the Agent Pool, for creating the Agent Pool, Go to Organization Settings and Navigate to Pipeline, Under Pipelines, click Agent Pools to access the agent pool settings.
  • Click on Add Pool and fill required details such as “Win10Agents”. You should also check pipelines permissions so required access are granted.
  • So Far, we have created the agent pool with name “Win10Agents” but no agent is added into the pool, so navigate to New Agent Page and agent as per your system (32bit x86 or 64bit x64). Click the Download button to download the agent and configure it on your machine.
  • Make sure your machine has these prerequisites:
    1. Windows 7, 8.1, or 10 (if using a client OS)
    2. Windows 2008 R2 SP1 or higher (if using a server OS)
    3. PowerShell 3.0or higher
    4. .NET Framework6.2 or higher
  • Once Downloaded, it can be configured easily, Unpack the agent into the directory of your choice. Then run config.cmd. This will ask you a series of questions to configure the agent.
Azure Agent Configuration
  • You will require to enter the “Organization URL” and “PAT” which is –
    • When setup asks for your server URL, for Azure DevOps Services, answer https://dev.azure.com/{your-organization}.
    • When setup asks for your authentication type, choose PAT. Then paste the PAT token you created into the command prompt window.
  • Once done, You can run the agent using the .run or Simply right click and run as administrator.
  • Under agent pools, you should be able to now see the Windows 10 build machine online.
The Complete Guide to UiPath CI CD with Azure DevOps 3

Other Configuration Steps

To add an Orchestrator Service Connection (based on the tenant)

  1. In the Azure DevOps project, click on Project Settings on the bottom left of the page.
  2. Click on Service connections under Pipelines.
  3. On the top right of the page, click New service connection.
  4. Choose UiPath Orchestrator Connection as the type and click next.
  5. For on-premise Orchestrators, you will be using Basic Authentication with a username and password. Specify the Orchestrator URL and tenant as well.
  6. Name the connection (it is a good idea to include the environment and tenant in the name) then click save.

To add variables to store client id/user key etc.

  1. In the Azure DevOps project, click on Project Settings on the bottom left of the page.
  2. Click on Library under Pipelines.
  3. On the top of the page, click + Variable Group. for this example, we have given group name as “UiPath”
  4. You can now add all the variables you need inside the pipeline. (for our use case we need Orchastarator API Details so so that we can publish the package to the different environment )
  5. For reusability, you should create different groups for different environment and projects. this will help to restrict the usages.
Azure Pipeline Source Code Variables

To change the list of approvers

  1. In Azure DevOps project, select Environments under Pipelines.
  2. Select the environment you wish to edit.
  3. On the top right, click on the ⋮ icon to expand the menu.
  4. Select Approvals and checks.
  5. Either select the existing approval or create a new one if none exist.
  6. Add or remove approvers as needed.

Complete Working Example for UiPath CI CD Pipeline With Azure DevOps Project

Example #1 - Using azure-pipelines.yml (Pipeline codes in Project )

Pipelines Details 

As discussed, Pipelines are the top-level component of continuous integration, delivery, and deployment. In this working example, we are going to create a pipeline comprising- 

  1. Build Stage – This will create build artefacts using a self-hosted agent
  2. Deploy Stage – This will publish the packaged.nupkg to the UAT orchestrator 
  3. Test Stage – This will run Test Cases with the published package in UAT.
  4. Deploy to Prod Stage – Finally, the package will be deployed in PROD env.

This example will give you the required information to set up your pipeline. You can add the required stages accordingly.

Working Pipeline Yaml Code

            trigger:
  - master
variables:
  - group: DEV

stages:
  - stage: Build
    displayName: Build Package
    jobs: 
    - job: BuildPackage
      pool: LAPTOP-Q338O4FK
      steps:    
      - task: UiPathPack@2
        inputs:
          versionType: 'AutoVersion'
          projectJsonPath: '$(Build.SourcesDirectory)\project.json'
          outputType: 'Process'
          orchestratorConnection: 'UiPath DEV'
          outputPath: '$(Build.ArtifactStagingDirectory)'
      - publish: $(Build.ArtifactStagingDirectory)
        artifact: drop

  - stage: Assest
    displayName: Create Assests
    jobs:
      - job: CreateAssests
        pool: LAPTOP-Q338O4FK
        steps:
        - task: UiPathAssets@2
          inputs:
            orchestratorConnection: 'UiPath DEV'
            folderName: 'Shared'
            assetActionType: 'Deploy'
            csvFile: '$(Build.SourcesDirectory)\Data\Assests.csv'

  - stage: DeployDEV
    displayName: Deploy build artifact to DEV
    dependsOn: Build
    condition: succeeded()
    jobs:
      - deployment: deployDEV
        displayName: Deploy package to DEV Orchestrator
        pool: LAPTOP-Q338O4FK
        environment: DEV
        strategy:
         runOnce:
          deploy:
           steps:
            - task: UiPathDeploy@2
              inputs:
                orchestratorConnection: 'UiPath DEV'
                packagesPath: '$(Pipeline.Workspace)\drop\'
                folderName: 'Shared'
                
  - stage : CodeQuality
    displayName: Check Code Analysis
    dependsOn: Build
    condition: succeeded()
    jobs:
      - job : CodeQuality
        steps:
          - task: SonarCloudPrepare@1
            inputs:
              SonarCloud: 'Sonar'
              organization: 'rpabotsworld'
              scannerMode: 'CLI'
              configMode: 'manual'
              cliProjectKey: 'rpabotsworld_UiPathAzureDevOpsExample'
              cliProjectName: 'UiPathAzureDevOpsExample'
              cliSources: '.'
          - task: SonarCloudAnalyze@1
          - task: SonarCloudPublish@1
            inputs:
              pollingTimeoutSec: '300'


  - stage: TestDEV
    displayName:  Test After Publish
    dependsOn: DeployDEV
    condition: succeeded()
    jobs:
      - job: TestDEV
        pool: LAPTOP-Q338O4FK
        steps:
          - task: UiPathTest@2
            inputs:
              testTarget: 'TestSet'
              orchestratorConnection: 'UiPATH RPABOTSWORLD'
              testSet: 'UiPathAzureDevOps_Tests'
              folderName: 'Shared'
              testReportDestination: '$(Pipeline.Workspace)\drop\'
        

Stage Overview

Stages in UiPath Azure Devops

You can see the details of individual stages by navigating to jobs run details page. 

The Complete Guide to UiPath CI CD with Azure DevOps 4

Example #2 - Using project-pipeline-template.yaml (Pipeline code as Library)

Library for Staged pipeline with an approval process for production releases

Now Playing 1/1
Mastering Azure DevOps CI/CD Pipeline for UiPath Development: Automate Your RPA Delivery
            # Staged pipeline with an approval process for production releases.
#
# Approvals are not defined here, but rather tied to the environment. 
#
# As is, this pipeline template will deploy to the DEV environment on commits to any developement* branch without approvals,
# will deploy to the UAT environment on commits to any release* branch without approvals,
# and will deploy to the Prod environment on commits to the master branch, after approval.

parameters:
# The full path to the folder containing the project.json file for this pipeline
- name: 'projectPath'
  default: '.'
  type: string
# The name of the folder to deploy the package to.
- name: 'folderName'
  default: 'Default'
  type: string
# Either AutoVersion to generate a build number or CurrentVersion to match the project.json version.
- name: 'versioningStrategy'
  default: 'CurrentVersion'
  type: string
# The environments to update the package version to the deployed version. 
# Not required for modern folders or if you do not want to update the package version.
- name: 'environments'
  default: ''
  type: string
# The name of the testSet to be executed 
- name: 'testSet'
  default: 'Azure.Devops_Tests'
  type: string
  
# This pipeline is broken into stages for the approval functionality. Stages are ran independantly, which means the pipeline can pause until the approval is received. 
stages:
# Build the nuget package.
- stage: Build
  jobs:
  - job: BuildJob
    pool:  Default # Update this if using dedicated build pool
    workspace:
      clean: all
    steps:
    - script: 'echo project path: ${{ parameters.projectPath }}, folder name: ${{ parameters.folderName }}, versioning strategy: ${{ parameters.versioningStrategy }}, environments: ${{ parameters.environments }}'
      displayName: Log parameters
    - task: UiPathInstallPlatform@2  # This installs required exes. Not necessary if using a dedicated build machine.
    - task: UiPathPack@2
      inputs:
        versionType: ${{ parameters.versioningStrategy }}
        projectJsonPath: '$(Build.SourcesDirectory)\${{ parameters.projectPath }}'
        orchestratorConnection: Orchestrator-Dev-Default  # Update this to a service connection for your Orchestrator.
        outputPath: '$(Build.ArtifactStagingDirectory)\Output'
    # Publish the nuget package for later stages.
    - publish: $(Build.ArtifactStagingDirectory)\Output
      artifact: drop

# Deploy to the Test environment on commits to any release* branch.
# Note that this stage has no environment defined, and won't have approvals.
# For Test environment approvals, update this to look like the Prod stage, but with using the Test environment.
- stage: DeployToTest
  condition: and(succeeded('Build'), startsWith(variables['Build.SourceBranchName'], 'development'))  # Only run if the packaging succeeded and we are on a development* branch.
  jobs:
  - job: DeployToTestJob
    pool: Default  # Update this if using dedicated build pool
    workspace:
      clean: all
    steps:
    - download: current
      artifact: drop
    - task: UiPathInstallPlatform@2  # This installs required exes. Not necessary if using a dedicated build machine.
    - task: UiPathDeploy@2
      inputs:
        orchestratorConnection: Orchestrator-Dev-Default
        packagesPath: '$(Pipeline.Workspace)\drop'
        folderName: ${{ parameters.folderName }}
        environments: ${{ parameters.environments }}

- stage: Assest
  displayName: Create Assests
  jobs:
    - job: CreateAssests
      pool: Default  # Update this if using dedicated build pool
      steps:
      - task: UiPathAssets@2
        inputs:
          orchestratorConnection: Orchestrator-Dev-Default
          folderName: ${{ parameters.folderName }}
          assetActionType: 'Deploy'
          csvFile: '$(Build.SourcesDirectory)\Data\Assests.CSV'

- stage: Testing
  displayName:  Test After Publish
  dependsOn: DeployToTest
  condition: succeeded()
  jobs:
    - job: TestDEV
      pool: Default
      steps:
        - task: UiPathTest@2
          inputs:
            testTarget: 'TestSet'
            orchestratorConnection: Orchestrator-Dev-Default
            testSet: ${{ parameters.testSet }}
            folderName: ${{ parameters.folderName }}
            testReportDestination: '$(Pipeline.Workspace)\drop\'


# Deploy to the Prod environment on commits to the master branch.
# Will require approvals as defined by the environment in Azure Devops.
- stage: DeployToProd
  condition: and(succeeded('Build'), eq(variables['Build.SourceBranchName'], 'master'))
  jobs:
  - deployment: DeployToProdJob
    pool:  # Update this if using dedicated build pool
      vmImage: 'windows-latest'
    workspace:
      clean: all
    environment: Production  # Update this to your Prod Enviornment in DevOps. This is where you configure the approval process.
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop
          - task: UiPathInstallPlatform@2  # This installs required exes. Not necessary if using a dedicated build machine.
          - task: UiPathDeploy@2
            inputs:
              orchestratorConnection: Orchestrator-Dev-Default  # Update this to a service connection for your Prod Orchestrator.
              packagesPath: '$(Pipeline.Workspace)\drop'
              folderName: ${{ parameters.folderName }}
              environments: ${{ parameters.environments }}
        

Using the template repository in the Project folder

            # Copy this file to you project's root directory (containing the project.json)
# then update the variables and paths trigger as a appropriate.
#
# The resouces section points to the repository containing the pipeline templates. This is set to UiPath's repository.
# DO NOT use the UiPath template repository for anything other than testing. It may change without notice.
# Please fork/replicate this repository to host it yourself and make any required modifications.

variables:
  # The full path to the folder containing the project.json file for this pipeline
  projectPath: project.json
  # The name of the folder to deploy the package to.
  folderName: Shared
  # Either AutoVersion to generate a build number or CurrentVersion to match the project.json version.
  versioningStrategy: AutoVersion
  # The orchestrator tenant to deploy to. Not used, but may be useful if deploying to multiple tenants.
  tenant: DEV
  # The environments to update the package version to the deployed version. 
  # Not required for modern folders or if you do not want to update the package version.
  environments: ''

# Update this trigger to specify when the pipeline should run.
# Variables cannot be used here.
trigger:
  # Define what branches trigger the pipeline
  branches:
    include:
      - master    # Will push to Prod after approval
      - development # Will push to DEV without approval
      - release*  # Will push to UAT without approval
  # Define what paths to include for building this pipeline. Normally, you should add the same projectPath as above,
  # so that any change to the project will trigger the pipeline, but it will ignore any changes to other projects.
  paths:
    include:
      - '*' # same as '/' for the repository root

# This points to the repository containing the templates. Update this to point to your template repository. Using the Concept of DRY.
resources:
  repositories:
    - repository: templates
      type: github  # use 'git' for a repo hosted in Azure DevOps
      endpoint: rpabotsworld
      name: rpabotsworld/UiPath-Azure-Devops 

# Use the above specified template for your project. 
extends:
  template: project-pipeline-template.yaml@templates  # Template reference
  parameters:
    projectPath: $(projectPath)
    folderName: $(folderName)
    versioningStrategy: $(versioningStrategy)
    environments: $(environments)