- Release Notes
- Introduction
- Governance
- Source Control
- CI/CD Pipelines
- Feeds Management
- Logging
Solution deployment with Pipelines
UiPath® Solutions Management enables deployment of automations together with all their required resources. To integrate this into the Automation Development Lifecycle, UiPath® Automation Ops™ - Pipelines, added support for Solutions Deployment. Now, you can test and re-deploy a Solution automatically with every code change of your automations.
To make the full value out of this pipeline you need to be familiar with the Solution concept in UiPath® context. For more details, see Solutions Management Overview.
You can use use pre-built pipeline from Marketplace. You need to download the Marketplace package, create a process out of it, and assign the Solution specific roles, as detailed in the following steps:
-
Download the Solution Deployment Pipeline package from UiPath® Marketplace.
-
Create a pipeline process in the Pipelines runtime folder in Orchestrator. To check your Pipeline runtime folder in Orchestrator, go to Pipelines > Runtime settings, as shown in the following example also:
-
Assign the Pipelines robot account the Solution Administrator tenant role. You need to assign this role in all the tenants the pipeline will manage solutions.
The following list provide a summary of the steps involved in the Solution Deployment Pipeline process:
-
Cloning the repository.
-
Going line-by-line through the Solution pipeline configuration file, and for each project there (each line), analyzes it, runs tests, builds a new package version, publishes it, and updates the target process (specified in the Solution project).
-
Synchronizing the Solution project, so it becomes aware of the new versions of the automations.
-
Publishing the Solution package in the first environment.
-
Downloading the Solution package configuration file.
-
Deploying the Solution.
-
Activating the Solution.
-
Suspending for approval.
-
Downloading the Solution package from the first environment and uploading it to the second environment.
-
Deploying the Solution to the second environment.
-
Activating the Solution.
The following table describes the available pipeline arguments.
Name | Description |
---|---|
Analyze policy | The governance policy holding the workflow analyzer rules used in the pipeline process. If left empty, the analysis of the project is skipped. |
OrchestratorUrl |
The URL to the Orchestrator where automation packages are published. |
SolutionProjectName | The name of the Solution project. It is used to identify the Solution project.
|
SolutionPackageName | The name of the Solution package that will be created. |
SolutionPackageVersion | The version of the Solution package that will be created. |
AppendBuildNumberToSolutionVersion | Enables adding a suffix with the Build Number to the Solution package version. This is useful to avoid version conflicts for subsequent pipeline executions. For more details about the default arguments, such as Build Number, see Default pipeline process arguments. |
SolutionPackageDescription | The description of the Solution package. |
SolutionRootFolder |
The root folder under which all the Solution components are deployed. |
SolutionPipelineConfigurationFile (Optional) |
The relative path of the Solution pipeline configuration file to the repository root (such as
solution-pipeline-configuration.csv) . If not provided, the projects will not get rebuilt, and the Solution package will be recreated solely based on the information
in the Solution project.
|
FirstTenant |
The tenant name where the Solution project is defined and where the Solution will be first deployed. |
FirstDeploymentFolder |
The folder in the first tenant where the Solution will be deployed to. It will be the parent folder of the Solution root folder. If empty, the Solution will be deployed at the root of the tenant. |
SolutionFirstDeploymentName |
The name of this installation, for future reference. One solution package can have multiple deployments. |
DeployToSecondEnvironment | Enables the rest of the pipeline related to deploying the Solution in the second environment. |
SecondTenant (Optional) |
The tenant where the Solution is deployed second time. If not present, FirstTenant is used. |
SecondDeploymentFolder (Optional) |
The folder in the second tenant where the Solution will be deployed to. It will be the parent folder of the Solution root folder. If empty, the Solution will be deployed at the root of the tenant. |
SolutionSecondDeploymentName (Optional) |
The name of the second installation, for future reference. If not present, the First deployment name is used. |
TestingFolder |
The Orchestrator folder where test are executed. It works together with the OrchestratorUrl argument. |
SkipTesting |
Disables/Enables performing the tests. By default, the pipeline runs the tests. |
ApproverEmailAddress |
The email address of the user that approves the deployment to the second environment, typically after the validating the first deployment. It is used to assign the approval task in Action Center. |
SupportUserEmailAddress (Optional) |
The email address of the user who can step in and fix solution deployment errors if necessary. If not present, the pipeline will break in case of solution deployment errors. Note:
The pre-built pipeline is generic. It could not contain logic to cover the mandatory deployment configuration of each specific Solution. This is why when deployment fails, the pipeline suspends and asks for manual fix. To avoid this, you can use the Solution package configuration file in your custom pipeline. |
SkipSync (Optional) |
It can be used to recreate a solution package without any updates. |
SkipValidation (Optional) |
Skips validation during the project building step. |
In case of a failed deployment, an action task is created for support, and the pipeline suspends, so it can be fixed. Once the deployment is fixed, the action task needs to be completed, in order to resume the pipeline execution.
When fixing a deployment, please wait for the deployment to reach the Successful Status before completing the task.
To manually fix a deployment issue, go to Solutions Management > Deployments, identify the deployment, and select Resume deployment wizard, as shown in the following example also:
The Solution Deployment Pipeline process is pre-built to cover most of the use cases. However, you can customize it, to meet your needs. To do this, you need to retrieve the template from Studio and fine-tune it. For more details about templates in Studio, see this section.
Make sure that in Studio > Templates, the Include Prerelease option is enabled.
To create a a custom pipeline, follow this steps:
-
Create your Solution project in Solutions Management.
-
Keep your automation projects under Source Control in GitHub or Azure repositories. All your solution's projects code must be stored in the same git repository.
-
Add a new configuration file (for details, see Solution pipeline configuration file) to your repository that keeps the mapping between the Automation used in the Solution project at Step 1 and the respective projects paths in repository. The following example shows a Solution pipeline configuration file:
-
Assign the Pipelines robot account the Solution Administrator tenant role. You need to assign this role in all the tenants the pipeline will manage solutions. The Pipelines robot account is the robot account used for running the pipelines and it is assigned to your Pipelines folder in Orchestrator.
For more details about Pipelines robot account roles, see Initial setup.
You can find your Pipelines folder in Orchestrator by checking Runtime settings in Pipelines.
-
Create a pipeline in Automation Ops. To trigger the pipeline whenever a change occurs in the entire repository (any of the solution's projects changes), select only the repository, not also the project at the first step of the pipeline definition.
-
Set the pipeline arguments and start your pipeline.
The Solution pipeline configuration file maps the automations used in the Solution to their source code projects. The pipeline needs such a mapping to know what projects to build, and where to place them in order to update the Solution. This format is just a proposal used by the pre-built pipeline. You can use your own format when you create you custom pipeline process.
.csv
file with the following format:
PathToProjectJson,PackageName,OrchestratorFolder,ProcessName,RunTests
PathToProjectJson,PackageName,OrchestratorFolder,ProcessName,RunTests
.csv
file and it is required.
Each of the lines configures the actions that are performed on a project:
Name | Description |
---|---|
PathToProjectJson |
The relative path to project.json from the root of the repository. |
PackageName |
The name of the package created from the project. |
OrchestratorFolder |
The location where the process will be updated in Orchestrator. |
ProcessName |
The name of the process to be updated. |
RunTests |
Whether to run tests or not as part of the pipeline. |
PathToProjectJson,PackageName,OrchestratorFolder,ProcessName,RunTests
Blank Process 16/project.json,Blank.Process.16,Finance,Blank.Process.16,True
ComputeSLA/project.json,ComputeSLA,Finance,ComputeSLA,False
PathToProjectJson,PackageName,OrchestratorFolder,ProcessName,RunTests
Blank Process 16/project.json,Blank.Process.16,Finance,Blank.Process.16,True
ComputeSLA/project.json,ComputeSLA,Finance,ComputeSLA,False
The Solution package configuration file is the file used to control the automated deployment configuration of the Solution.
The Solution pipeline configuration file is different from the Solution package configuration file. The Solution pipeline configuration keeps the mapping between the Solution and the project. The Solution package configuration stores the Solution components configuration for deployment.
A typical use case for it is setting the passwords in Credential Assets used in the Solution.
Credential Asset passwords that are part of your Solution are not stored in the Solution package and you need to specify it during deployment.
To set the password as part of the pipeline you need to download the Solution package configuration file and update accordingly.