Retool apps can be synced with a Git repository, letting you customize how you develop and deploy Retool apps across multiple environments.
The most common approach is to have multiple instances of Retool: development, staging and production. Code promotion across environments is controlled via Git, so that every change must be reviewed as a pull request before being promoted to a higher environment. Engineers can safely build Retool apps on the development instance, can run tests and perform QA on the staging instance, and end-users can access the applications on the production instance.
Option 1: Automatically Sync Changes
In this version of Git Syncing, the development instance is configured to continually push changes to a dev branch while the staging and production instances are configured to automatically watch and deploy code from the staging and master branches, respectively. Your engineers will only have access to edit applications on the development server, while the staging and production apps will be locked.
Option 2: Develop Using Feature Branches
Note: Option 2 is only supported with GitHub today.
Once an application is deemed worthy of promotion, the engineer “Protects” the app in the development instance, which will sync the application to GitHub in a new branch. Only apps that are explicitly synced to GitHub will ever make it to the staging and production instances.
This approach has two benefits: (1) engineers can treat the development instance as a “sandbox” environment, without worrying about all the apps showing up in staging or production, and (2) it supports feature branches, so that individual apps can be promoted to production without having to sync all your apps at once.
Note that in both flows, the Staging and Prod instances of Retool are only pulling from their respective branches. If, for some reason, someone has edit access to a Retool app running on one of these instances, Retool will alert them saying they cannot make changes through the UI. This is done by setting
VERSION_CONTROL_LOCKED=true in that instance's
Updated 2 months ago