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 –
A CI/CD pipeline workflow usually consists of the following discrete steps:
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) 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.
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 –
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-
Let’s quickly discuss the key concepts used in the azure pipeline.
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.
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!
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.
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-
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
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.
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.
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.)
Once access for source code has been granted, you need to specify whether you are going to use.
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.
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 –
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.
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.
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.
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.
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.
Import-Module UiPath.Powershell
$token = Get-UiPathAuthToken -ClientId $(uatClientId) -UserKey $(uatUserKey) -AccountName $(uatAccountName) -CloudDeployment ‘Production’ -TenantName $(uatTenantName)
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 ]
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.
Download Azure DevOps agent as per your system (32bit x86 or 64bit x64) configuration and Operating System.
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.
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-
This example will give you the required information to set up your pipeline. You can add the required stages accordingly.
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\'
You can see the details of individual stages by navigating to jobs run details page.
Library for Staged pipeline with an approval process for production releases
# 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)
Sign in to your account