Retool Versioning Explainer

Hi Everyone!

Just wanted to share a little write up @sophie and I have been working on for how to best use Retool's Release Manager to work together inside of Retool: Release Manager/ Versioning Explained: How to Develop Together Best in Retool

In the tutorial we explain how to reduce the chances of publishing unfinished work, how to best collaborate inside of Retool, common misconceptions about Retool's release manager and what to do when things do go wrong and you do have to rollback a release.

Here is a tldr if you don't get the chance to read it :slight_smile:

TLDR

  • The production and staging tab in Retool means data only, this switches the backend, but the app stays the same
  • More than one person cannot work in the same Retool app at the same time
  • The last person to close the app, saves their version. Never leave the app open in a tab on your browser when you are not editing it
  • To make edits without affecting the live version, use the release manager. Create a draft release to edit that one, and then publish when you are ready to push to live.
  • Never publish a version without checking the changes first. This is especially important when working in teams, as you never know if you are publishing their half-finished edits.
  • You can also view and revert individual changes in the ‘History’ tab of the Release Manager, where you can see each change that has been made, and by whom.
  • If you need to fix a bug or release a patch version while you are working on some larger, unfinished edits, revert to the live version before fixing this problem, publish this, and then revert the working back to the environment you were working on (make sure you fix the bugs/add the small edits to this one too!)
  • For multiple developers needing to work on a critical bug at the same time (to try and find the solution) , you can duplicate the app and work in this copy version.**
3 Likes