Version Control in bluprism

[Anonymous]

This is regarding the version control in blueprism to allow access of modifying an object/process at same time by multiple users. Suppose if one person is working on a process(say Process A) and if some other person wants to work on the same process(Process A), we don't have the flexibility for the same unless anyone of the person has closed/completed working on the process. It would be helpful if the multiple users can access a process/object at the same time in blueprism similar to version control

[John__Carter]

BP has never had the capability for multi-user editing, and in my experience most of the time this is not much of an inconvenience. I agree it would be a 'nice to have', but consider the difficulty in merging a diagram that two users have edited - if each user radically changes the layout, what would a merged diagram look like? We did give this a lot of thought in the early days but soon realised it would be a recipe for trouble.Design can help a lot with collaboration: rather than create a single 'mega' object, it's better to create a series of small objects, each one focussed on a particular screen or function of the target application; a solution can also be formed of multiple processes, simplifying the development, and crucially, the testing.

[RajeshKizhakkev]

Hello - Does BluePrism support integration with other version control systems like SVN or TeamCity ?    Thanks,

[JohnnyPrescott]

I'm upping this one because this is big lack in Blue Prism. Having two environment for Dev and Prod is totally inconvenient as the queue data is unavailable within the Dev environment, which cause us to go debug directly in production. This is stupid but often not a choice we have unless we go and copy the queue data from the prod DB to the dev one, which is even more impractical.   Having something similar to a git server for the processes would help a great lot. You branch and work on it and still can do everything. You merge it back only when you're done. And if having the merge system is too complicated with the way BP is built right now, I could suggest simply having a similar system which would integrate only one branch. It would lock out the main one so no one can still use it but would give the possibility to work on the side and save while not affecting the currently running processes.

[John__Carter]

You should not have only dev and prod environments. You need a test environment that has access to live data where you can conduct tests in  'attended' and 'unattended' mode. Production should always run 'unattended' and you should certainly not make any changes in Prod. See https://portal.blueprism.com/system/files/2018-02/Delivery%20Roadmap.pdf and https://portal.blueprism.com/system/files/2017-11/Blue%20Prism%20-%20Introducing%20your%20Process%20to%20Live%20Data.pdf

[Denis__Dennehy]

Having two environment for Dev and Prod is totally inconvenient"" - that comment made me laugh!  That sounds more like an Automation Anywhere methodology than a Blue Prism enterprise operating model!!  🙂  Of course it is inconvenient, it is also more safe and secure.  It sounds like your organisation does not have a logical operating model in place so would fail a capability assessment audit. As for mutli-developer editing of objects, JC is correct, our training is very strong on this - you should have lots of small objects for your applications which among other benefits (such as lower risk change) will allow multiple developers to develop against the same application at the same time.

[JohnnyPrescott]

Well then, I am not sure what is being teach to the vendor selling BluePrism then because this is what has been setup in our environement. :) We started using BP well before we even had access to the forum and website and unfortunately didn't went through the training on here but through theirs which seems a lot less fleshed out. We ended up implementing a lot of our stuff on our end directly because of this. Fortunately, we switched to BP directly a few weeks ago so we might correct this going forward. Maybe at the same time we go from version 5 to 6.

[JohnnyPrescott]

I am still in favor to a branch system that just ""replace"" the original instead of merging. This would be a lot easier to manager than dev and prod (and test) Prod ==> Branch to Dev ==> do your modification ==> push to Testing phase ==> submit for review ==> Prod Prod could never be modified directly that way and people would work in the same UI interface.

[Denis__Dennehy]

Fair enough Johnny - give your Partner a telling off from me.  The developer training path is very clear (same for everyone), and it starts with joining the portal and taking the Basic Awareness Survey!!   To be delivering solutions before accessing the Portal is a big shout out that something is wrong. Even if best practice is used with small objects to decrease risk and allow multitiple developers - I agree that true version control within the product with branching would be good to have.

[JuhoVihonen]

Is there any hope of getting this kind of feature in near future, 2019 maybe? There would be use in change management in certain environments and situations due to target system version management resource by resource.