Solution Deployment Pipeline

Use Automation Ops - Pipeline to include Solution Management in your Automation Development Lifecycle.

To make the full value out of this pipeline you need to be familiar with the Solution concept in UiPath. Please read more about it here: Solutions Management Overview.

This pipeline process is pre-built to cover most of the use cases. To customize it, please find this Solution deployment pipeline template in Studio and fine-tune it. More details in documentation: Automation Ops - Solution deployment with Pipelines (uipath.com)

How to use this process in Automation Ops - Pipelines

1. Go and create your Solution project in Automation Ops.
2. Keep your Automation projects under source control in GitHub or Azure Repos. All your solution's projects code should be stored in the same Git repository.
3. Solution pipeline configuration file: Add a new 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. More details about the Solution pipeline configuration file are presented below.
4. Download this Marketplace package and create a process out of it in your Pipelines Runtime environment (the Orchestrator folder used by Automation Ops - Pipelines). You can identify it on the Runtime settings panel in Pipelines homepage in Automation Ops.
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 the project at the 1st step of the pipeline definition.
6. Set the pipeline arguments and start your pipeline.

This pipeline performs the following steps:

1. It goes line-by-line through the Solution pipeline configuration file, and for each project, it (each line) analyzes, runs tests, builds a new package version, publishes it, and updates the target process (used in the Solution project).
2. Synchronizes the Solution project, so it becomes aware of the new versions of the automations.
3. Publishes the Solution package in the first environment.
4. Downloads the Solution deployment configuration file.
5. Deploys the Solution.
6. Activates the Solution.
7. Suspends for approval.
8. Downloads the Solution package from the first environment and uploads it to the second environment.
9. Deploys the Solution to the second environment.
10. Activates the Solution.

Notes

• In case of a failed deployment, an action task is created for support, and the pipeline is suspended, so that it can be fixed. Once the deployment is fixed, the action task must be completed before resuming the pipeline execution.
• 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 states the properties of the Solution artifacts at deployment.

The Solution pipeline configuration file is a CSV file with the following format (that should be met):

PathToProjectJson, PackageName, OrchestratorFolder, ProcessName,RunTests

The first line is the header.

• PathToProjectJson: Project.json relative path to the repository root.
• PackageName: How the package is named.
• OrchestratorFolder: Where the process will be updated in Orchestrator.
• ProcessName: Process name to be updated.
• RunTests: Whether to run tests or not as part of the pipeline.

Pipeline arguments

1. 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.
2. Orchestrator URL: The URL to the Orchestrator where automation packages are published.
3. Solution project name
4. Solution configuration file path [optional]: Relative path of the Solution pipeline configuration file to the repository root. (e.g. 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.
5. Solution package name
6. Solution package version
7. Deploy to second environment: Enables the second environment deployment.
8. First deployment tenant
9. First deployment folder
10. First deployment name
11. Approver email address: Email address of the user who approves the deployment to the second environment.
12. 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.
13. Second deployment tenant [optional]: If not present, First Deployment Tenant is used.
14. Second deployment folder [optional]: If not present, the pipeline will perform only the first deployment.
15. Second deployment name [optional]: If not present, the First deployment name is used.
16. TestFolder: Folder in Orchestrator where tests are executed.
17. SkipSync [optional]: It can be used to recreate a solution package without updating it with latest changes.
18. SkipValidation [optional]: Skips validation during the project building step.