cancel
Showing results for 
Search instead for 
Did you mean: 

Handling multiple versions of same Business Object

MadsPedersen
Level 2

Hi,

I want to start by saying I come from an UIPath background which has a capability that doesn't seem to be present in Blue Prism, so I would like to ask how/if others have solved similar issues with dependency management.

The thing is in my development team we have a set of business objects that are widely used by different processes, which again are developed and maintained by different people. 

This locks us in in terms of updating input/output parameters of the objects. If we do so we would have to at the same time update all the processes which are dependent.
It also makes the release to production process harder since an object might have unfinished code which have been changed due to requirements for Process B, which is in development, after the test of Process A have been signed off.

Similar if the object is already present in production, updating is more nerve wrecking as we might introduce unfinished code.


In UIPath this is solved by having a package manager where each component is handled as a .nuget package . If we say a BP Business Object is like a UIPath library, I as a BO/Library maintainer can release a new version at my leisure, since all dependent processes developers actively have to choose the newest version and incorporate  it in their code, including test.

How do you manage changes and dependencies on a larger scale? 

As a side note, I can say we all connect to the same servers in the different environments (DEV, TEST, PROD), so we don't have a local BP server/database installed on our own machines. 


1 REPLY 1

peterlacken
Level 7
Hi Mads,

I feel your pain.  The UiPath package and version control is nicer and more sophsiticated than Blue Prism.  There is only 1 version in Blue Prism! We combat this by delivering to production regularly (weekly) and developers are fully aware that they can not just half bake code as it may go to Prod the following week.  We often must take a copy of the Action or Page and develop on the copy. Only when the copy is fully tested can we switch names (for Actions)  and reference to Page (for Page) keeping the old code but renamed to "OLD" to make rollback easier. The "OLD" is then deleted the following week.  Hope that helps ! Not pretty but functional 🙂