.jpeg)
The Release Manager (or Versioning) in Retool is a super useful feature for splitting up your work into shippable units and version controlling your apps. Nevertheless, it can cause a bit of confusion, and it’s easy to make a big mistake: overwriting recent dev work or accidentally pushing an unfinished app to the live version can be a little bit too easy sometimes, especially when working on the same app with other developers. In this post we will clear up how the release manager system works, and how best to work with versioning in a team to avoid any crucial mishaps.
To clear up some of the terms we use, here is a glossary that you can refer back to if you need:
First things first, let’s take a look at how Retool Versioning works.
This release manager will allow you to create different versions of your app, helping to avoid many sticky situations - especially the ones we’ll go through in this post. This versioning feature allows you to create both live and draft versions of the app, and for multiple developers to save their own edits without overwriting other people’s work.
You can access this by clicking on the three dots in the top-right corner of your app, and selecting ‘Releases and History’.
This will bring you to a modal where you can create and publish your versions. Click ‘Create New’ to make a new version.
The next part is fairly self explanatory - decide whether the version is major or minor, or a patch, and make sure to describe your version clearly (only app developers can see this) to help communicate the differences between versions both to yourself and your team (trust us on this - always use the description).
The next step is either to create a draft release, or use the dropdown to create a live release: ‘Create and Publish’. For the first version you create when your app is ready to go live, go ahead and use the latter. When you are creating subsequent versions that aren’t yet ready to go live, create a draft release.
Here’s a rundown situation of how you might use this feature as a single developer, without a team:
Another handy resource within this modal is the ‘History’ tab (as you can see in the image above), which allows you to see each individual change that has been made, and by whom. This is really useful to check through as well as compare changes, to see if someone else has been working in the app before you publish. You can also use this option to revert individual changes without reverting the entire app version.
Now that you have different versions, you can preview each of them individually too - just click the dropdown icon next to the ‘Preview’ button and select which version you’d like to view (this is also handy for quickly seeing which Version is in the working environment, and which is currently live)
If you’re not using releases in Retool, then the relationship between the app you’re editing and what your users see is pretty straightforward – they’re one and the same. If you’re building something personal or small, that may be no problem. But for mission critical apps, or even apps used by a team for an important task, you want to follow software engineering best practices and version your work.
A common misconception with Retool is that there is a staging and a production version in each app, and that a developer ‘pushes’ changes from staging to production. This issue probably arises from the ‘Staging/Production’ toggle in the working environment: this relates to your backend only, the Retool app itself is exactly the same in both cases, it is only the resource that changes - so that you can switch yourself to ‘staging’ and mess around with your app without touching the live data itself.
In fact, if you aren’t using the release manager, there isn’t a difference between the working version (what you see when editing your Retool app), and the live app that people are using. This means that edits you make in the working environment automatically apply in the live version when they refresh or re-enter the app, and thus, the editing and live app are the same.
Here’s an example situation to elaborate:
The good news is, it is entirely possible to create a current working version in Retool that separates from the live version using the Release Manager. Keep reading to learn how to do this (and if you already know - how to do it properly and avoid the easy mistake of publishing unfinished work).
While it is possible to collaborate in Retool apps and do dev work together, it’s important to do so with care and great communication.
It is currently not possible to edit Retool apps (or be in edit mode) at the exact same time as another teammate. This may work in very rare circumstances, but 9 times out of 10, you’ll just delete another person’s work. Retool will show you if someone else is in your app in the top right corner - make sure to keep an eye on this! Communicate immediately with anyone who is looking at the app at the same time as you, as this is where big issues can occur.
The bigger problem: while it may be possible to negotiate separate times to work on Retool apps to avoid clashes, there is one critical way to cause major issues: the open tab overwrite.
If you take nothing away from this blog post, take this away at least: always close out your shared apps when you are done working with them. Why? Because when two people are working on an app at the same time, there are two parallel cached working environments trying to save to one version of the app, and it’s the last person to CLOSE the app, who saves their version, overwriting the other person’s work.
Let’s clarify this idea with another problem situation:
As you can see from this story, huge amounts of hard work can be lost, simply by one of your devs leaving the Retool app open in a tab of their browser. This is one of the easiest mistakes to make, and one of the most costly.
In sum: always close the app when you are finished working with it, even if just for a few hours.
Here’s to our next common problem in Retool: the accidental-half-finished-edits publish. Many people are already using versioning within their apps to stagger releases, but what they aren’t doing is checking that the version they publish is correct and complete.
Here is an all-too-common scenario with dev teams:
As you can see in this scenario, Dev 2 mistook the working version to be a brand spanking new copy of the version currently live to users: Dev 2 didn’t understand that the current working version they just published included the edits made by another developer. They therefore missed one very crucial part of this process: Compare Changes. Communication between developers can’t always be perfect, but one way you can check up on the situation in the app before publishing is to check the changes of the version you are about to publish. This feature will show you a side-by-side comparison of the live and the version you have selected.
If you see a huge amount of changes (as well as your critical bug fix), you may be about to publish someone’s half-done work. Always (always!!!) check the changes before hitting publish on a version, as you never know what someone else has been fiddling with without you realizing.
Okay, so you’re actually here because you’ve published half finished work into your live application, and you want me to tell you how to fix it - no fear, we’re here (and all is not lost).
A key thing to remember here is to communicate well with your team, and anyone else involved. A very simple mistake to make is a team member hopping into an app, updating a simple field to reflect an API change and hitting publish, without realizing how much they are really publishing.
So we’ve run through how to fix the problem, but here’s how to avoid it too. This is the best way to make a small update or fix when you’re in the middle of different edits that aren’t ready to go live.
One option that may be useful for dev teams is duplicating the app - we would only recommend this as a way of working on an app (e.g. to figure out how to fix a crucial bug) at the exact same time. This may be useful if you have a critical issue that requires two eyes, but can’t afford to lose time by taking turns.
This simply involves duplicating the app in the app menu (the three dots in the top-right corner), working on the copy, and then redoing whatever fix you came up with in the original app. This isn’t really an ideal fix however, since you’ll have to replicate changes made in the original application once the other developer exits.
Bold Tech were the right fit for TVadSync to accelerate our use of Retool platform. We had both user experience design needs as well as back end data design needs that were quickly resolved by the team. We will be using them for all Retool app development moving forward. Highly recommended.
Joey and the Bold Tech team have been an invaluable help for us this past year. Quick, efficient, straightforward and a real pleasure to work with, I can not recommend them highly enough!
We build internal tools, fast.
