Retool development process at Huspy
Retool development process at Huspy
In this document we will explain how teams at Huspy should work with Retool, so that they can control the delivery/deployment process, make it scalable and embrace the approaches we use for another codebases (Python, Kotlin or TypeScript).
Retool source control and protected Apps (optional)
The procedure for integrating source control with GitHub is detailed in . Huspy adheres to these guidelines, ensuring consistency and transparency in our setup. AWhile we advocate for this methodology company-wide, teams consisting of 1-2 engineers working on isolated apps may forgo this step to streamline their development process. All Ops Portal apps reside in t
Make the app protected
Before leveraging source control, it's imperative to make your app 'protected'. The process is straightforward and outlined in . You can click “Protect app” and follow the instructions from the document.
Work with protected app
If need to make changes in the protected App, you should follow the steps described in this section.
Retool apps releases
The concept of versions and releases in Retool is described in . Whether or not you're utilizing source control for your Retool apps, it's essential to comply with the foundational release policy. This safeguards the end-users from unpredictable changes.
Post completion and successful integration of your app modifications into the primary branch (provided you're employing source control), initiate a new release. The release should contain the description of the changes and follow the .
Once the release is tested by the QA engineer, it can be deployed to production (see the picture below).
By adhering to this guide, Huspy teams can ensure smooth, organized, and efficient workflows when working with Retool.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.