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.

Note:

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.

Using the pre-built pipeline

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:

1. Download the Solution Deployment Pipeline package from UiPath® Marketplace.

   
   
   
   
   

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

   
   
   
   
   

3. 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.

Solution deployment pipeline steps

The following list provide a summary of the steps involved in the Solution Deployment Pipeline process:

1. Cloning the repository.

2. 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).

3. Synchronizing the Solution project, so it becomes aware of the new versions of the automations.

4. Publishing the Solution package in the first environment.

5. Downloading the Solution package configuration file.

6. Deploying the Solution.

7. Activating the Solution.

8. Suspending for approval.

9. Downloading the Solution package from the first environment and uploading it to the second environment.

10. Deploying the Solution to the second environment.

11. Activating the Solution.

Pipeline arguments

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.

Handling deployment issues

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:

Creating a custom pipeline from the template

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.

Note:

Make sure that in Studio > Templates, the Include Prerelease option is enabled.

To create a a custom pipeline, follow this steps:

1. Create your Solution project in Solutions Management.

   
   
   
   
   

2. 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.

   
   
   
   
   

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

   
   
   
   
   

4. 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.

   
   
   
   
   

5. 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.

   
   
   
   
   

6. Set the pipeline arguments and start your pipeline.

   
   
   
   
   

Solution pipeline configuration file

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.

The Solution pipeline configuration is a .csv file with the following format:

PathToProjectJson,PackageName,OrchestratorFolder,ProcessName,RunTests

Important:

The first line is the header of the .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.

The following is an example of a configuration file:

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

Solution package configuration file

The Solution package configuration file is the file used to control the automated deployment configuration of the Solution.

Important:

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.