My org has numerous 19.1 projects that we combine into solutions like:
top level: solution
middle level: WinApp & Web app projects
bottom level: commonUtility library project
Using the conversion utility 19->22 it creates one solution for the top level with all the code pulled together. that breaks our portability/reuse of the middle level. turning the projects into assets seems the way to go, but how do I maintain “import” mapping when recombining the separate asset project into each other and top level v22 solution. Looking for suggestions/articles..
@RobIsTheName The way to do this is to upgrade the lowest level projects as assets first. Once all the child projects have been upgraded and deployed as assets, then upgrade your main project and select “Use Project Assets”. This will find the ones you’ve deployed (either into Robot Manager or into your %AppData%\Pegasystems\Assets folder) and use those instead of the project code.
https://docs.pega.com/bundle/robotic-automation-221/page/robotic-automation/advanced-automation/project-assets.html
Let me know if you’d like me to put together an example. If so, please send me a diagram showing your current project relationships, as I can build something from that to replicate.
Hi @ThomasSasnett,
Our understanding is that if we add the asset to the main project, it becomes “read-only”. How can developers troubleshoot in the main project if the asset doesn’t work as planned? Any ways, the developer can temporary modify the asset code for troubleshooting purpose before updating the asset project?
Regards,
Fiona
@FionaCherryIt is best to think of an asset like a finished product. You can troubleshoot it as much as you wish but changing it would defeat its purpose as a separate, tested and deployed entity. If you wish to modify the asset, you would need to check the code out of source control.
I would make sure that your asset is tested and complete before you elect to publish it. Once it has passed all of your unit testing, then your other developers would be able to use it in its stable state. If they determine it lacks something or has a bug, then the owner of the asset should be responsible for changing it, testing it, and then re-deploying the asset.
Hi @ThomasSasnett,
It makes sense if it’s a brand new build. With all the legacy/existing codes in v19.1, it could be challenge for us to manage those after the version uplift.
Do you have any recommendation?
Regards,
Fiona
@FionaCherry Presumably, your project that you wish to convert to an asset is working now. If so, then you should upgrade it and perform unit testing on it. If it passes the unit testing, then deploy it as an asset to be used in the larger project. Do this for each of your assets as you reconstruct your main project with these assets. If that doesn’t meet your needs, you can always convert to assets later, albeit at an added labor effort. It is best to decide now, so that you can avoid as much technical debt as possible.
@ThomasSasnett @FionaCherry: I have no problems with the concept of “assets” being completed, read only products. In fact that’s the way we (should) treat our current 19.1 solutions with multiple sub projects. Each sub project is a completely separate solution, with the deployable component used in a parent solution.
This mimics the Asset concept v22. The trouble trying to move to v22, is on several levels:
-
Assets with Global objects are not accessible by parents (they are in 19.1 with subprojects)
-
Assets need to be able to be compiled via a DevOps pipeline (in 19.1 we do this by linking subject in GIT) v22 currently doesn’t have that option (yet)
-
With a code base of 40+ solutions, each have 3-8 subprojects we need a migration path that doesn’t involve massive rewrites. Assets comes close, but does quite match up to the object oriented abilities of 19.1 /visual studio provides.
We have escalated this with a service incident (INC-C22640) and will pursue further on that case…
Really appreciate the candid comments and input