Forum Discussion

Lucian's avatar
Lucian
Community Hero
7 years ago

How does your organisation handle ReadyApi versions?

Hi,

 

Different versions of ReadyApi may have different bugs/ working stuff. For instance, there were some json path assertions which worked on 2.1.0 but didn't work on 2.3.0. This became an inconvenient in our team where everybody is using whatever version they like to use. 

 

I'm thinking of 2 approaches now. Either:

1. Make so that everybody is using a certain version - say we use now the ReadyApi 2.4.0 and stay with it no matter what new versions come out.

2. Make so that everybody updates to the latest version (every time a new version appears).

 

How does your team work with this? Do you have any advices from previous experience?

 

Thanks!

  • groovyguy's avatar
    groovyguy
    7 years ago

    To ensure maximum capability, we try to keep everyone on the same version. Usually, when a new version comes out, I will run through it first and see what the differences are and if there are any changes like you mentioned that would drive a lot of re-work. If so, I'll usually hold off upgrading my team until we have time to consume those changes. If not, I'll usually have my team upgrade and go from there. 

  • groovyguy's avatar
    groovyguy
    Community Hero
    7 years ago

    To ensure maximum capability, we try to keep everyone on the same version. Usually, when a new version comes out, I will run through it first and see what the differences are and if there are any changes like you mentioned that would drive a lot of re-work. If so, I'll usually hold off upgrading my team until we have time to consume those changes. If not, I'll usually have my team upgrade and go from there. 

  • nmrao's avatar
    nmrao
    Champion Level 3
    7 years ago

    Here is what I see this one as:

    1. Multiple versions On Single Machine: More than one version of ReadyAPI can co-exists on single machine(use command line to use specific version rather than windows short cut which might be pointed to latest version). That makes it simple to use whatever version we want any point of time. In this case, the concern is that whether project opened / saved in latest version be compatible with previous version or not. To avoid the risk, having the projects under configuration management/repository such as git / svn etc would help to revert to any version that was compatible with older version of ReadyAPI.


    2. Common Test Machine: Another test strategy is that use a separate test machine(which is common to the team), which I believe is one of the best approach, where the tests can be run / executed continuously (even using Continuous Integration). Just do the upgrades on this machine. If the tests goes fine well and good. If not, any way continue to use previous version (as per #1).

    This is even helps to reduce the load on individul team members / engineer's machine; they can focus on developing the tests and execute the tests on test machine.

    3. Upgrade Criteria: You may also define the process when to upgrade for your team or organization. Instead of going for the each upgrade, you can go for it on meeting your criteria such as
    a. the upgrade has fixes to your critical issues
    b. new feature enhancements that you might require
    c. fixes for any performance bottlenecks.

    Of course, you can define your own criteria.

    Hope this helps.


    • nmrao's avatar
      nmrao
      Champion Level 3
      7 years ago
      And one more general practise for upgrading the software is the 3rd digit / service pack updates. Because, major and minor versions (first, second digit respectively) tend to have defects due to major changes to the software or enhancements and those are mostly addressed in service pack (third digit).

      For example:

      Go for version 5.1.1 rather than 5.0.0 or 5.1.0.
  • Radford's avatar
    Radford
    Super Contributor
    7 years ago

    A bit late to the game but I thought I'd share how we handle upgrades. In short, we keep everyone on the same version and upgrade as little as possible.

     

    First thing when a new release comes out we review the change logs, is there a new feature we really need, or has a bug that seriously impacts us been fixed? If not skip the upgrade, "If it aint broke don't fix it".

     

    This has meant we take very few upgrades. When there is a new version we want, we carefully test all of our projects, and then raise all the issues with SmartBear support, getting these fixed in the nightly maintenance build. When we got to a point where we were happy with the build, one person will "upgrade" all of our projects in source control, and then we deploy the software to all users. We then only allow installation via automated software deployement, so this then ensures everyone is on our very specific maintenance build.

     

    We are in fact we are still on version 1.7 and by the time we deployed it 1.8 was already just out, as there were multiple issues we found and got addressed by support. While a bit painful and time consuming this has meant that Ready API has since been very stable for us and on a day to day basis works without any problems.

     

    As a side note we are now thinking that we will look at taking the 2.4 upgrade.

  • Lucian's avatar
    Lucian
    Community Hero
    7 years ago

    I think this is exactly the answer I needed. Thanks!