Our company is new to using Retool and wants to explore the possibility of the Source Version control integration in the Retool. We have close to 50-60 screens already built and working in Production, but we do not have SVC yet.
So appreciate this community's help in clarifying the questions we have about this integration.
We understand we need Retool Enterprise plan to work with the source version control integration.
Once I have the license and am integrated with Github, can I have all of my screens' code in Github (CSS, JS, SQLs, API calls, or any other resources) so that we can have the changes reviewed as PRs?
Meaning, in the unforeseen situations, if my Retool server goes down completely, can I still have all the code in Github that I can migrate back to Retool and have the screens up and running on the new server?
I assume this Github integration allows branch based deployments, is it correct? Because currently each screen seems to have a version, and the developer makes changes on top of it, and marks the same version as "Live" version for it to be available in Production. Can we do branch or tag based deployments to each environment in this scenario?
We would greatly appreciate your inputs on the above, as I mentioned, our company is using Retool for the first time, so wanted to know these details before we acquire enterprise license.
Hey @sridhar_g - welcome to the community and thanks for reaching out!
Yes - almost every primitive within Retool can be serialized and checked into source control - apps, resources, Query Library queries, and workflows. I don't think agents can be protected just yet, but I think that will probably come before too long. Once a primitive is checked in, the only way to modify it is via a PR.
Yes - you can populate a brand new deployment by connecting it to an existing source control repository.
Yes - app development is all done via branches and PRs after configuring source control, but that doesn't mean you can't still utilize app versioning. There's a great community topic on this from one of our engineers.
Appreciate and Thank you for your response, Darren.
When raising the PRs, how would we see the changes to the app that we have made? I mean, will everything be stored in a single big json file and all the changes (from all primitives) be inside that single json? I am trying to see whether it will be hard and difficult for the reviewers if we have a single json with all the code in it in a PR review.
Could you please let me know your thoughts on the above.
Great question - reviewing PRs and resolving merge conflicts used to be a pretty painful process when app content was serialized as YAML. We've since developed and released a new serialization standard called Toolscript that makes app content much more human-readable, which has been a very welcome change for PR reviewers!
