Tracking Application Versions Across Environments

  • 16 March 2021
  • 3 replies
  • 7 views

Hi Everyone, 

Just wondering how do you manage application versioning across environments? I know that K2 tracks versions of all its components,  but these version numbers do not travel across environments when we do packaging and deployment, and we end up struggling sometimes to verify, for instance, whether UAT and PROD are having the same version of the app or not.

Thank you


3 replies

Hi mitwallim,

 

Seems like the scenario that you have described is related to the information in the link below 

https://nintex.uservoice.com/forums/932677-k2-five/suggestions/42431401-a-form-view-smartobject-workflow-version-that-pers

 

The above link provided is a forum wherein you can log a new feature request or vote for other.

If you would like the above to be implemented you may vote on the link above or log a new request,

Everyone that works in your office can vote on the idea to get more attention from the developers so that they can be considered for future updates.

 

Should you feel that this post is of use and or an accurate solution to the raised question, I kindly encourage you to mark it as such 
using the 'Best Answer', 'Like' andor ‘Me Too’ options.

 

Cheers,
Kate

 

K2 will not accept any liability for any issues arising from actions taken in respect of the information provided by any forum member.
 


 

Thanks @kateV . Will do. I still hope to see how the community is handling this need at the moment. 

Userlevel 5
Badge +13

As part of our application lifecycle, we make sure our environments get updated in lockstep. That is, when we do a release for a particular application, I build a package off of DEV that has all of the components for that application, even if they weren’t updated in this release (all forms, views, processes and SmartObjects used by the application). This package then goes to UAT, so at that point we are certain DEV and UAT are identical. When everything gets finished being verified in UAT, then that same package gets pushed to PROD and we know that all three environments are identical.


If, during testing on UAT, you have to make changes to something then I follow the same steps again - build a package off of dev that includes ALL components and push it to UAT to verify. This also gives you a rollback if a particular update doesn’t go well - I save all of our full release packages so if, say, Release 03 has a problem during deployment I can just deploy Release 02 and be confident that it has ALL components needed to run the application in that particular version.

I hope this makes sense, happy to elaborate further if it is unclear. 

 

Reply