Which Versioning control system tool or Configuration Management tool works well with Blue prism?

[Prem_KSundar]

Which Versioning control system tool or Configuration Management tool works well with Blue prism?

Suggest between
1. TFS
2. PVCS
3. Sub version
4. Github

How to enable in blue prism tools settings or Control room. Please suggest any steps.

------------------------------
Primo
Manager
Zoetis
America/New_York
------------------------------

[AshishEasow]

Hi,
Personally i have worked with subversion and Git, both were fine for me. No preference as such for version control. For basic operations the existing BP version control works. But then again its every organisations choice. If in case you are worried about having automated release management, then BP help has command lines for importing and exporting what would matter is, if you are using an external code repository and you want to automate it, it depends on how easy would it be to integrate with BP. 
The would be a job for your build and deployment tool for eg, something like jenkins (not your code repo) , which would need to

1. Integrate with your code repository (which ever you choose, if its not BP)
2. Get the release file/artifacts
3. Deploy onto the required server.
The is no direct integration of such tools with BP, you will have to create custom scripts for deployment. I have tried basic deployments with jenkins, it was fairly easy.
but then its better for you to explore and try out your own use cases as it would depend on those.

hope that helps.



------------------------------
Ashish Easow
Senior Consultant - Professional Services
Blueprism
Asia/Kolkata
------------------------------

[AndrzejKaczor]

I'd love to learn abotu the version control in BP - if anyone can write few more words about that then I'd love to read it.

------------------------------
Andrzej Kaczor
RPA Dev
Arla Foods Ltd.
Europe/London
------------------------------

[AntonBotha1]

Version control is where BP falls short from the competitors. There is no way to have different versions. You can only have different releases. The release versions you can control. This is a problem for me personally as an organisation has many developers working on the same code base while creating branches. With BP all developers work on the same code base. Extremely risky.

------------------------------
Anton Botha
------------------------------

[DaveMorris]

Anton brings up a good point about where BP falls short, and I just wanted to provide a counterpoint to that. While I agree that BP does eventually need to support at least multiple versions of the same process/object, I think it's important to remember BP's perspective. It's not designed for use primarily by programmers. Granted, programmers make the best Blue Prism developers, but that just wasn't the focus. BP is intended to be as friendly as possible to a Business User/Analyst who wants to learn to develop process automations.

I think that Blue Prism has several versioning benefits out of the box that other tools do not have. For example, with very little effort in set up, you have centralized repository of code without needing to understand or participate in branches/pulls requests/commits/etc. You double click on a process, drop some stages in, and close the process. When you close it, BP asks you if you want to save. And even if something happens where BP crashes (32 bit apps do that sometimes lels), the autosave feature defaults to 10 minutes so typically you'll never lose more than 10 minutes of effort. If your computer blows up, your code is safe because it is constantly saving to the central repository stored in SQL Server. Without any technical knowledge, you can make edits to a process or an object and then immediately someone else can go in and edit that same process object (after you've closed it).

So, in my opinion, it depends on what's most important to you. I'll be the first to criticize BP (the product) for anything I see designed poorly or not tested well, but in my opinion the version control/versioning isn't deficient. It's just different.

------------------------------
Dave Morris
Cano Ai
Atlanta, GA
------------------------------

[AntonBotha1]

Very nice sales pitch Dave! What you forget is that BP is marketed to very large organizations with established IS and development teams. These organizations already have formal procedures in place for version control and deployment that needs to be followed in order to have a new piece of work deployed to production. Automated deployment to production and backing out of a deployment are some of the reasons why versioning is extremely important. If BP wants to position their product as a easy entry, quick learn product it is fine but in the big scary world of scaled IS operations the versioning is lacking and not adequate to fulfil the requirements of structured and mature IS departments.

------------------------------
Anton Botha
------------------------------

[DaveMorris]

There's no sales pitch. Blue Prism really was designed with that in mind. Please don't take my counterpoint to mean that I disagreed with what you said. And whether or not anyone thinks Blue Prism's marketing technique matches up to its intended design isn't really the point. If Blue Prism were truly as user friendly as possible, we'd be able to create environment variables from inside of a process and things like that. I was explaining that there's a reason Blue Prism is designed the way it is. Besides, large organizations typically make a distinct separation between development teams and business teams. The idea was that Blue Prism could put automation in the hands of business users, guided by IT. That has been the message for years now. If that's what guides Blue Prism in their choice of future features, I seriously doubt we'll ever see much integration with external version control.

------------------------------
Dave Morris
Cano Ai
Atlanta, GA
------------------------------

[Walter.Koller]

In my humble opinion BP did a quite good job to provide change control.
I generally agree though, (better) integration to external source/version control would be much appreciated.
Below are some thoughts on this topic. Any comments are very welcome.

There is impact and dependency features, which needs central repository, managed by BP. Otherwise 'offline' analysis have to be made, like export all content run (external) tool to gather all references, and do this regularly, at least whenever there is a change. Which I think might come quite often in the case you described of having multiple developers working on same code base. We had to do this for in another project (something completely different to RPA) and in the end it took them up to two days to impact analysis, sometimes showing conflict that made another iteration necessary. Of course it does not have to be always like this.

For directly working with external repository, Blue Prism might need to revise on how it works with XML to not suffer performance degradation. 

I don't see any problems to integrate BP into existing release and deployment processes. We have been successfully evaluating the deployments with UC4 but stopped because of our current set-up with independent development teams. But the steps for automated deployments can be easily scripted and orchestrated with UC4, including a code-freeze source control tool. The manual steps involved here do not differ much from working with other tools. But my knowledge in this matter might be limited.

Creating branches for hot-fixing the current version while developing further the main is not possible out of the box and something to think about. It is also not so uncommon to create a separate hot-fix environment. I suggest to have such hot-fix environment, in order to run full system and integration tests.
Although I have to admit this is shooting with canons when the fix was to add eg a missing semicolon. Not all fixes might be so simple and other fixes involves several objects and that will be difficult to resolve with only one development environment.

BP processes are modular (at least they should be designed like this). So normally there should be no conflict with two people working on the same objects/processes. However this might happen. If it happens more often, structuring into smaller pieces should be considered, like it is also true for classic SW development. The concept of having processes (logic) separated from VBO (actions) is quite neat. VBO should be seen as units, sliced into the size that makes sense for your development approach and are the actual point of development. Processes glue everything together and VBO can be assumed as black boxes, mostly relevant when it comes to system/integration testing.

Edit:
In our case, BP internal change tracking might have been one of the reasons to select BP over other RPA tools. The initiator of RPA came from business in a 'let's have a look' approach, not having the resources for full integration into release and deployment processes. Time changed since then and we have three independent development teams, not all of them have in-depth experience in SDLC though.