Hi all,
I'm the CTO of a company that uses Retool Cloud extensively as its backoffice, and we love it.
Our 1 major pain point with Retool is that it does not fit well in a modern CI/CD pipeline with multiple environments. Unfortunately this problem is pervasive enough that we are actively looking to replace Retool.
I would like to have much greater control over which Retool App version is published to which Retool environment.
Currently we manually need to remember to "publish" an app version after we deploy the backend API, making it really easy to forget or make mistakes.
Specifically, if I make an update to a Retool App that is dependent on a change in our backend API, then I cannot publish that App's new version until our backend API is deployed to all environments. Otherwise, in some environment, that Retool App will be calling an old version of the API and experience errors.
Examples of current common issues
- Publishing an App when the supporting backend is still not published in production, means the App will only work in pre-prod environments
- Not publishing an App because you're waiting for the supporting backend to be deployed in production means testing the App in pre-prod requires manually switching to a newer version. Leads to a lot of friction between developers and testers surrounding which version should be checked and why features are not working
- Time between finishing working on an App and actually publishing could be long - up to a week in our case. In that time you could be looking at multiple Apps that needs publishing, some of them could have been updated multiple times, could lead to publishing the wrong version
Implementation suggestions
The implementation must consist of two parts
1 - Separation: Allowing Apps to have different versions deployed to different Retool Environments.
2 - Control: Allowing App editors to deploy a specific App Version to a specific Retool Environment.
Implementing separation
This might be hard to implement but easy to understand: Each App Version should be able to be deployed to Environments separately. If I have an App with versions 1,2,3, I should be able to have Version 3 deployed to dev, Version 2 deployed to staging and Version 1 deployed to production.
Options for implementing control:
Option 1 (extremely granular control):
API based: Give us an API that accepts the following parameters: retool_app_id, version, environment.
This API would publish the app with ID retool_app_id, in version version, to environment environment.
This approach gives a ton of control to me but also requires some
Option 2 (more streamlined but much more opinionated), my favorite option
Give me a button/API that promotes all apps versions from one environment to the next.
For example, let's say that when I publish an App Version, I publish it to dev (this could be manually selected in the existing App Publish modal).
Then, allow me a button that promotes all App versions that are on a specific environment to a different environment. For example, I would promote all Apps on dev to staging. This would publish every App Version that's currently on dev to also be on staging.
Option 3 (most opinionated):
Create a new "Release" concept, which holds together different App Versions that are to be released together.
Once I'm ready for a "Release", I can choose to deploy a specific Release to a specific environment. This means that all App Versions in the Release will be published to that environment.
This means that as I develop a Retool App, instead of "Publishing" it, I can add it to a Release.
Then, I can choose to deploy that Release to dev. All of the App Versions in that Release will be deployed to dev.
What this request is not
I'm not asking to replace the existing controls, only to add new ones that help with coordinating releases. It is extremely important to keep the existing controls in order to allow quick fixes to different environments.