Blue prism code versioning

[GowthamAlluri1]

Hi all,

I have a scenario where i am working on one version let's say 3.0 but i got an urgent requirement where i need to release a version let's say 2.1 with few changes. I was thinking of taking the prod version and make the changes and release new version that is 2.1 but i need to make those changes in 3.0 also where i need to put effort on integration and if this is quite recurring scenario we are wasting efforts on integrating the code.

What is the best way to address this issue??

------------------------------
Gowtham Alluri
Senior Software Engineer
EY
------------------------------

[harish.mogulluri]

Hi Gowthami Alluri,

In general its best practice to use different environment like, Dev, QA, Pre prod and Production.

If you are changing the code in dev or QA as mentioned in 3.1 version you can use pre prod environment for the latest change which can be deployed later to prod.

If you dont have different environments then only way is you need to override the existing process and deploy different versions based on your need.

------------------------------
-----------------------
If I answered your query. Please mark it as the "Best Answer"

Harish M
Lead developer
America/New_York TX
------------------------------

[GowthamAlluri1]

Hi Harish,

We do have multiple environments and we can make changes and deploy but integration should happen again in the major version which needs some effort. If this is going to be frequent , then lot of effort will go on integration. I need some suggestions on this if there is any best practice followed in industry.

------------------------------
Gowtham Alluri
Senior Software Engineer
EY
------------------------------

[Babjee24]

Hi Gowtham,

Have the logic written differently for two versions in the same process and separate it with a flag value and pass this flag value as a startup parameter. This will help you route through different logic.

But if the versions are many then this is not the best way of approach. If you have a couple of different versions then this would work.

Hope this helps...

------------------------------
Babjee Vangipurapu
Senior RPA Developer
Wonderbotz
India
------------------------------

[PvD_SE]

Hi G,

Indeed, this is a problem where BP does not provide us a simple solution.

A way to avoid this is to not make changes to a process while the previous version is still quite fresh in production. In other words: only when a version is considered mature, then you can open the process again for further changes.

If this is not possible, you will end up with duplicate work, or the parameter solution as described by Babjee. Personally, I'm not really in favor of such a solution as it requires the schedules for the process to be adjusted for a new, yet temporary, parameter.

------------------------------
Happy coding!
---------------
Paul
Sweden
------------------------------

[GowthamAlluri1]

Thank you Babjee and Paul for taking time and replying.

I will try to explain the problem again . I have a version which is 2.0 in production now and i am working on major release with many enhancements which is version 3.0 and lets say planned release date is in November. Between now and November, i got an urgent requirement to be delivered in 2 or 3 weeks and these changes are completely new and not part of  version 3.0.

In such scenario, we typically take the current prod version and deploy into another server (QA or UAT) , make the changes, test and deploy it in production. Now these changes have to be integrated in version 3.0 as well right which is planned for later date. hence ,we are wasting the time or duplicating the work  by integrating it in version 3.0 which is under development . 

If this happens multiple times until the next release, we are wasting lot of time on integration, so, i was checking if there is better way to do it.

Thanks

Gowtham A

------------------------------
Gowtham Alluri
Senior Software Engineer
EY
------------------------------

[Tejaskumar_Darji]

What if you create well-organized individual pages for each change in order to handle minor enhancements more efficiently? Then, when it comes to the major version 3.0, you can copy and paste entire pages containing all the minor enhancements.

This kind of scoping and agreement is bound to bring up issues, whether it's in the context of any tool or software development.

Ideally, the definition of a major release should include a provision for minor release versions as well. It's not feasible to commit to a major change without considering the inclusion of minor changes that were not initially anticipated. Also, efforts should be included for such scoping model to consider this scenario.

------------------------------
If I was of assistance, please vote for it to be the "Best Answer".

Thanks & Regards,
Tejaskumar Darji - https://www.linkedin.com/in/tejaskumardarji/
Technical Lead
------------------------------