[轉]UIPath進階教程-6. Architecture & Publishing flow

本文轉自：https://blog.csdn.net/liaohenchen/article/details/88847597

版權聲明：本文爲博主原創文章，遵循 CC 4.0 by-sa 版權協議，轉載請附上原文出處連接和本聲明。
本文連接：https://blog.csdn.net/liaohenchen/article/details/88847597

There are various ways of designing the architecture and project flow - depending on the infrastructure setup, concerns about the segregation of roles etc.
In this proposed model UiPath developers can build & test their projects on Development Orchestrator. They will be allowed to check in the project to a drive managed by a VCS - version control system (GIT, SVN, TFS etc).
Publishing the package and making it available for QA and Prod environments will be the work of a different team (eg IT).
The deployment paths on Orchestrator have been changed from default to folders managed by the VCS (by changing packagesPath value in web.config file under UiPath.Server.Deployment)
The model also contains a repository of reusable components.

Here is the project publishing flow, step by step:
 Developers build the process in UiPath Studio and test it with the Development Orchestrator; Once done, they check in the workflows (not packaged) to a Master UiProcess Library folder (on VCS);
 The IT team will create the package for QA. This will be stored on a QA Package folder on VCS QA run the process on dedicated machines
 If any issue revealed during the tests, steps above are repeated.
 Once all QA tests are passed, the package is copied to a the production environment (P Package)
 Process is going live, run by the production robots.
Reusable content is created and deployed separately – as UiPath code (Reusable Code Library) and Invokes (Invokes Repository).

So we distinguish here between the actual workflows with source code (.xaml files containing UiPath activities for automating a common process – eg Log in SAP)

and invokes (workflows composed of only one UiPath invoke activity of the code workflows mentioned above).

The Library of developer Studio should point to this Invoke repository in order to provide easy access (drag & drop) to reusable content.

The local design authority in charge with maintaining the reusable content will update (due to a change in process, for instance) the workflows with code. The invokes will remain unchanged.
The advantage of this approach (as opposed to work directly with the library of source code): when a change is done to a reusable component, all the running projects will reflect this change as well – as they only contain an invoke of the changed workflow.
 ————————————————
版權聲明：本文爲CSDN博主「liaohenchen」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處連接及本聲明。
原文連接：https://blog.csdn.net/liaohenchen/article/details/88847597