Cross Environment Version Control

[Jeff__Addinell]

Suppose at some point in the past a business object was developed in our Blue Prism Development environment and then imported into our Blue Prism Production environment. Also suppose that this object was edited and saved many times in the Development environment before and since it was imported. The question is, how can I tell today, which version history item in the Development environment is the one that is active in the Production environment?

[Neel1]

Hello @Jeff__Addinell  - You can easily check the date in both the env from version history by searching the object.

[Jeff__Addinell]

Thanks but I think that will only work sometimes. The version history date in the production environment shows the datetime it was imported, which may be some time after the artifact was packaged into a release file. If the artifact was edited in dev between the release file being created and being imported then I can't see how you can determine with certainty, at some later point in time, which version history item in dev was the one that imported into production.

[John__Carter]

Hi Jeff you can see the date a release was made, so you should be able to work out which version of a process or object was in the release imported.

So Prod import timestamp -> Dev Release export timestamp -> Dev change history

[Jeff__Addinell]

Hi John, 

So given the current version in prod has prod import timestamp of 16/04/2024 13:28:11, can you tell me which of the below versions in dev it was an import of?

Dev change history:        Release export timestamp:
17/04/2024 12:11:12          17/04/2024 12:15:12
16/04/2024 11:11:13           16/04/2024 11:15:13
15/04/2024 10:11:14          15/04/2024 10:15:14
14/04/2024 09:11:15          14/04/2024 09:15:15

Thanks

[John__Carter]

Hi Jeff - I would expect it was the nearest export, 16/04/2024 11:15:13, although logically it could have been one of the earlier ones. Ideally your implementation and change control methodology should govern the transition into prod.

[Jeff__Addinell]

Hi John, so it looks like there is no way to tell using the Blue Prism product alone which version in prod matches with which in dev and that this would need to be tracked externally e.g. by using a spreadsheet. This external tracking would be unnecessary if Blue Prism provided a feature to uniquely label versions - even if this was just a matter of Blue Prism automatically associating and displaying a guid for each change history item.

[devneetmohanty07 · Accepted solution]

I agree here with @Jeff__Addinell , since I myself have faced this issue in past.

For this reason, we started having release control handled using SVN in one of my clients before (even though I was not a fan of it) still the benefit was we could exactly determine the versions from commit messages and release tags very easily. We did not implement CI/CD back then, so the deployment process was manual, but it wasn't very complicated as such.

For the other clients where we did not have any version control system, the way we did the comparison in past was to import the suspected versions for these release files using import/export date from both DEV and PROD in another environment (let say Sandbox) and manually investigate the objects one by one which has taken a lot of efforts for us in past.

I definitely agree that there needs to be some sort of a field (possibly a version no. or GUID) that also should be exported out as part of the release package and again be used to tag the same.

P.S. this can be posted as a Product Idea for sure.

[Jeff__Addinell]

A product Idea "Environment Neutral Version History IDs" is now posted in respect of this