Hi, we're considering setting up Source Control for our apps, but I haven't seen any documentation about how to set it up to first merge to (and deploy to) a staging branch/environment.
Is that possible using Source Control in Retool?
Thanks.
Hi @Evan_McDaniel! Welcome to the community. 
I think the first decision that you and your org needs to make is identifying where the staging environment will live. There are generally two different approaches - either spin up an entirely new instance or a new space. The latter approach works for both cloud and self-hosted instances and is typically the simpler option, especially because you can directly copy over certain configuration options.
The important thing to know is that source control for each space can be configured separately! Your production instance will be connected to and auto-deploy from main, but the other can be connected to a development or staging branch.
I hope that helps, but am happy to answer any additional questions you might have!
Hey Darren, thanks for the response. OK, I was hoping for something a bit lighter weight than Spaces - something that allows us to work on the same actual app, but have an intermediate step that allows for manual or automated testing prior to merging to main.
Or, perhaps I'm overestimating the work involved in setting up another Space for this purpose. Is there some existing documentation about how to setup a flow like I'm describing?
Thanks.
It is possible to work collaboratively on a single branch, if that is sufficient for your particular use case! You'd be able to preview and test any apps on this branch before merging into main.
That said, I do think taking the time to spin up a new Space is probably worth the time investment. It's a fairly painless process on Cloud and just a little more complicated otherwise due to the requisite DNS configuration.
Once you've created the new space, all you need to do to get up and running is configure SCM and point it to a separate branch.
For example, I have an instance at toula.retool.com that is pointed towards the main branch in my remote GitHub repository and a separate Space at dev.toula.retool.com that is pointed towards the dev branch in the same repository.
Thanks Darren. OK, so if a point the new Space at a branch that was created off of our main branch, it will end up with the same apps as what we have in our main/production environment?
If so, you are right, that is quite simple and VERY powerful. 
Yep! That's exactly right. 
You can develop and test on one space and then all it takes to move everything to production is to merge the corresponding branch into main.
Excellent! I'm going to talk to my team about moving to this flow. Is there a way for us to try Source Control - can we go back after enabling it if it's not working for us?
Also, I'm assuming there are no cost implications to creating our "staging" Space. is that right?
Thanks!
1 Like
Glad to hear it! Let us know if you run into any challenges.
You can choose to disable Source Control at any time or even toggle it on and off for specific entities and there is no specific cost associated with defining a new Space.
Hey Darren, we're continuing to move forward with the staging Space method, but... as I'm starting to add more users I just wanted to double check that adding users to a space cost us, right? Assuming the user is already in the main Admin space?
Thanks.
Correct! At the Enterprise level, the number of occupied seats is determined by the number of unique users across spaces and instances.
That's great news. I'll post back here once we've implemented this process fully.
One feature request that has come up already is to be able to create a PR from the feature branch and have a base branch other than main. Not a huge issue as we just manually change it in the PR in GitHub, but... would be nice to have a setting for the default branch for PRs.
Thanks!
Hey, another couple questions have come up that I'm hoping you could help with:
- Are we still able to roll back to earlier Releases via the UI, or would we have to do that via rolling back in GitHub?
- We tried merging the main branch into the feature branch to get the latest changes (a common practice on our engineering team), but it didn't seem to work. Do you know if there's a way we can do that?
Thanks!
Hey Darren (or anyone else that knows), just wanted to follow up on these 2 questions. We're waiting on moving forward with our rollout until we know the answers.
Thanks!
Hey @Evan_McDaniel! Thanks for your patience.
Each application's versioned releases exist independently of source control, meaning you are free to promote or roll back within the Retool UI.
This is indeed a common pattern, but it's not currently supported very well. The primary reason for this is that local feature branches are primarily unidirectional. You can, however, force Retool to pull down a remote feature branch using the Reset branch menu option.
This makes it possible to rebase the remote feature branch on GitHub and then sync those changes to your local feature branch.