a6e5b969-be6e-4756-ae53-47d3cb899ca4.png

1f5934b1-a458-4841-b6a9-4de1add4ce7e.png

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](https://docs.uipath.com/solutions-management/automation-cloud/latest/user-guide/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 here: [Automation Ops Pipelines Studio project templates](https://docs.uipath.com/activities/other/latest/workflow/about-the-pipelines-activity-package) (make sure to check *Include pre-release* option)

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

1. *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 is presented below

1. 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 Pipelies homepage in Automation Ops.
2. 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 1st step of the pipeline definition
3. 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, there (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

[Note 1] In case of a failed deployment deployment, an action task is created for support, and the pipelines 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.

[Note 2] 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

**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. OrchestratorUrl: 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. (ex: 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 test 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

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 will the process be updated in Orchestrator
- **ProcessName**: process name to be updated
- **RunTests**: whether to run tests or not as part of the pipeline

Use Automation Ops - Pipeline to include Solution Mevelopment 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](https://docs.uipath.com/solutions-management/automation-cloud/latest/user-guide/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 here: [Automation Ops Pipelines Studio project templates](https://docs.uipath.com/activities/other/latest/workflow/about-the-pipelines-activity-package) (make sure to check *Include pre-release* option).

### 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 is 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, there (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.

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

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

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](https://docs.uipath.com/solutions-management/automation-cloud/latest/user-guide/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)](https://docs.uipath.com/automation-ops/automation-cloud/latest/user-guide/solution-deployment-with-pipelines)

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

About me