Environment Neutral Version History IDs

[Jeff__Addinell]

Currently it can be challenging to match the active version of a process/object in the production environment with the version history item in the development environment that it was imported from. Please see the post "Cross Environment Version Control" in the Product Forum for more detail.

The idea is for the Blue Prism product to display an ID column in the Version History table of each process/object. Blue Prism would ensure that this ID is globally unique. This ID would be preserved when importing process/objects into other Blue Prism environments. Because the ID is preserved it is then simple to say which version in one environment matches with which version in a different environment.

This could be implemented in a number of ways:

1. These IDs could be user-inputted as an optional field within the existing with Blue Prism Save dialog with Blue Prism ensuring global uniqueness, or

2. These IDs could be automatically assigned GUID values by Blue Prism

[Jeff__Addinell]

EDIT: The first implementation method (user-inputted IDs) actually would not need to be globally unique, just unique over the scope of the process/object in question.

[Walter.Koller]

Why the need of a unique ID?

Objects/processes have already a unique ID (although very hidden and it would help to see those IDs). What is missing is some version information (absolutely agree her). This should be added automatically in the description field when saving (similar to built version in SW development). Even better maybe would be a new field that could be easily used in DB queries (reports, comparison, ..) and may have certain restrictions (eg write protected generally or only admin can modify it).

Also related to this topic but a different approach would be to have the change history be part of the object itself. So all meta data remain after export/import and knowing the exact change time and users should make identifying the version in use easy. This would also help in case of several environments where branching may occur. eg:

environment A, object vABC -> export
env B import -> object vABC
env B change -> object vBCD
env C import -> object vABC
env C change -> object vCDE
env C change -> object vDEF
In this case matching the history object by random ID would be challenging as each of the environments has their own new version ID and I would need to track down the history in each environment for the most recent common ID. 

[Jeff__Addinell]

• Version IDs are only required to be unique per object/process
• Unique IDs are required per object/process in order to identify and distinguish different versions of the same object/process
• Preservation of version IDs between environments is required so the same version of an object/process can be identified when it exists in different environments, e.g. in order to tell quickly and beyond any doubt which version of an object/process from the dev environment is the version that is currently active in the production environment.

[Tejaskumar_Darji]

I completely agree that managing versions can be tricky and often requires manual work.

As an alternative, I put the version number in the description box on the main page. This way, anyone looking at the development and production environments can quickly see the version and understand the differences. However, there is still a chance that someone might change this information.

[Walter.Koller]

Thanks for the reply. 

I am in favor of this idea and don't try to convince anyone but I am just 'thinking loud'. Maybe it helps to flesh out the idea and get the best approach.

Having the version information unique within the context of an object is obligatory. Within the context of one single environment or when following a directed (only from lower to higher environments and no branching) development path this ID could be as simple as a monotonic increasing number that is incremented every time the object is saved. This would be some kind of a built number... so additional tags might be helpful to add the release status.  eg 

<status> <autom built nr>
<v0.1>   <1>
<v0.1>   <2>
...
<v0.1>   <100> 
<v1.0>   <101> -> reading for testing/release

A (global unique ID) GUI would just provide the information that objects are different. eg obj (id:A) is imported to another environment and changed (id:A>id:B); then the original is changed (id:A>id:C) and then imported to a third environment. Now there could be some other change either in the third environment or in the original and it is already difficult to say exactly where is what version without going through the history of all environment. At least the original environment has to maintain its history, which may get lost during migration (upgrade), creating forks, ... 

Also worth noting is that not all types of saves should automatically generate a version. eg when importing an object/release this type of information should stay untouched. 

Also with 'save as' maintaining the original version might be what is wanted. (as 'save as' creates just a copy of the same version as the original)