Good process for publishing releases? I'm finding myself clicking publish hundreds of times a day

App Building
1

I'm curious how people go about publishing changes to apps they are using regularly. I have a dashboard that my team and I use which I'm constantly tinkering with, and it's a pain because every time I make a change I have to go through like a 5 click process of opening the release menu, creating a release, saying publish now, clicking ok, etc. Is this just how people do it? The only reason I use releases is to save my own work because sometimes changes get lost or overwritten so I wish Retool just tracked history automatically like google docs. Am I doing something wrong? Is there a better way?

1 Like
2

Same here

1 Like
3

Someone correct me if I am wrong, but it does track it automatically?

If you want your team to have the latest, can you share the link to the app with _releaseVersion=latest as seen here?

4

While drinking my coffee this morning...

I decided to tinker with a UserScript to maybe help your dilemma. (It bothers me too so lets do something!)

This seems to work in reducing the amount of steps. I didn't know what to pick for the hotkey, so you can change it to anything you want. Mousetrap docs here.

It's nothing more than automating a few clicks and then focusing the input box to type :slight_smile: If you need assistance installing userscripts, let me know, I'm happy to help.

// ==UserScript==
// @name         Retool - Release Automator
// @namespace    http://gofortuna.com
// @license      MIT
// @version      2024-09-01
// @description  Reduce the number of steps to release an app version with a hotkey.
// @author       Kevin Hill
// @match        https://*.retool.com/editor/*
// @icon         https://www.google.com/s2/favicons?sz=64&domain=retool.com
// @require      https://cdnjs.cloudflare.com/ajax/libs/jquery/3.7.1/jquery.min.js
// @require      https://cdnjs.cloudflare.com/ajax/libs/mousetrap/1.6.5/mousetrap.min.js
// @grant        none
// ==/UserScript==
 
/* globals Mousetrap, $ */
(function() {
    'use strict';
 
    Mousetrap.bind(['command+/', 'ctrl+/'], async function(e) {
        const panel = $('[data-testid="ReleasesAndHistoryPanel::Container"]');
 
        const steps = [
            () => {
                if (panel && !panel.is(":visible")) {
                    $('[data-testid="ReleaseManagement::Launcher"]').parent("button").click();
                }
            },
            () => panel.find('button:contains("Create")').click(),
            () => $("#createRelease--trigger").click(),
            () => $('#createReleaseBox div[role="option"]').first().click(),
            () => $("#CreateRelease-description").focus()
        ];
 
        return runSteps(steps, 300);
    });
})();
 
async function runSteps(steps, delay) {
    for (const step of steps) {
        await step();
        await new Promise(resolve => setTimeout(resolve, delay));
    }
}
3 Likes
5

Cleaned up the code a little and posted it on GreasyFork.

1 Like
6

Thanks for your response, I mean technically it tracks in that you can "undo" things but I've found that functionality to be pretty unreliable. Seems like there's a 25% chance any time I undo that it won't fully undo or will make other unintended changes.

1 Like
7

Hi @Alex_Long, here is some context on what could be causing this issue:

8

Thanks Paulo but the issue I'm talking about in my original post is at a more general level. If I'm working on an app over days and weeks, I want to have it backed up so that I can't accidentally destroy all my progress by accidentally making a change and then closing the browser window or something. (or having another team member make a change and not reverse it) Simply tracking history in-browser and offering an undo feature doesn't solve this larger problem. So my current workflow is basically to use releases as a way of saving my work so it cannot be lost (or so that it can be restored if it is lost). I just wish those backups would happen automatically (like how Google Drive saves your edit history).

9

I wouldn't mind a minor Draft Release history that was automatically saved. If I knew that my app was in a good enough state yesterday but then a bunch of changes were made I had no clue where when or why they were made, I could jump back to a Draft state.

The issue I see here is that if someone was making other changes in parallel I'd be negating their work which I would never want to happen to me. Understanding the users that would be affected (users who have made edits since the last automatic Draft save?) and possibly being able to merge/resolve conflicts through the process along the way would be very powerful for collaborative efforts.

10

I hear you on this. At the root of this great feedback is that we don’t fully trust auto save in all scenarios. While it would be nice to not have to feel like a fallback mechanism is needed, I understand the reasons you’re looking for a safeguard against losing changes. I’ve surfaced the feedback from this thread internally. If there are specific times outside of using historyOffset that changes are lost, we’d love to keep collecting the feedback to further bolster auto save and ensure trust in it.

Still, there are some great ideas for features in here! We’ll be tracking the idea of a Google Docs-like change history as a feature request. I don’t yet know whether this is something the Product team will fold into their roadmap strategy, or what the engineering lift would be, but it does seem like it could make sense to add eventually — as long as it played nicely with logging multiple users’ changes as @pyrrho described.

In the meantime, I think that the releases feature you’re already leveraging is going to continue to be the most risk-free way to avoid lost changes, even though it is cumbersome.

11

Thanks Paulo. Yeah I mean just making releases fewer clicks would go a long way. Right now it's literally like 5 or 6 button clicks to make a single release: 1. Open the releases tab, 2. Click create new, 3. Expand draft release drop down, 4. Change to Create and publish, 5. Click Publish. I literally go through this 5 click sequence like 10-20 times a day at least, bringing up PTSD from having to "save your work" in MS Word back in the day lol.

Also regarding the auto-saving, to put it simply, it just doesn't work. I'd say there's a 70% chance that trying to undo changes causes unintended side effects. I really try to avoid undoing at all costs because even undoing something as innocuous as dragging a component will sometimes just wipe out all the work I've done in past 10 minutes.

2 Likes