Hello!
Managing numerous users in a Grist application can be challenging when implementing new features such as tables, columns, and widgets, since they must be developed and tested before being released to all users.
Is it possible to separate test and production environments in Grist?
I can duplicate my document to work on new features, but how to transfer the structural changes back to the original document after implementation?
Hi Kostya,
To the best of my knowledge, thereâs no clean way to have a test / production environment like youâre describing.
The closest suggestion I have is using âWork on a Copyâ in the Sharing menu. You can make changes there, then apply them back to the original document.
However, itâs a temporary copy - I donât know of a way to save it, then apply changes at a later date.
Hopefully someone else has some better ideas! 
Very interesting question! We donât have this function yet, so the only way to do it is a custom script that will compare schemas between docs and apply required changes.
Iâd be happy to help someone in developing something like that. I wonder if we can leverage existing tools, for example MS SQL server has a very similar tool Schema comparison overview - SQL Server | Microsoft Learn.
Iâve been wondering about this same problem, having to recreate things manually in Production after getting the desired state in Dev.
Iâm a ServiceNow developer normally, this has a fairly elegant solution in the platform there.
We use Update Sets to bundle work for a piece of development and export the Update Set as an XML file when completed and import to the higher environments.
Update Sets are rows on the Update Set table, they can contain a reference to other update sets as a batch if required.
Each change to the platform is recorded in the âCustomer Updateâ table and each row in this table has a reference to the current update set.
I could try to implement something like this myself with my own Dev and Prod Grist instances on my cluster and show you what I mean if you like.
Really interesting!
Iâd like to see such solution.
And youâre right - servicenow is a good example.
Maybe one possible workflow could be âas simple asâ to be able to download and upload a grist file that was based on the same revision when doing âWork on a Copyâ, which can then be merged?
There are hidden treasures in the Grist data model, which could help produce advanced data management workflows based on branching and Change Requests. Maybe you have seen Dolt or TerminusDB?
I used the web API for this.
You can copy the entire structure of a table. The data types etc. are also transferred.
I first built a data transfer from another source into Grist. However, I did not want to put the transfer into production. So I âclonedâ the table via web api and carried out my tests there.
The âonlyâ problem I had with this is that you cannot create empty tables. Therefore, you have to delete the first three tables (A, B, C) so that the tables are truly identical.
If this is self-hosted, you can simply go to <grist_url>/apiconsole and even test it manually.
This sentence is a little obscure for me. What do you mean by it?
Actually, it could also be interesting to think this together with the Example: Querying Grist with GraphQL REST wrapper to move closer also towards tracking schema ( Is there an open specification of the .grist file format? - #2 by paul-grist ) migrations in a programmatic, Infrastructure-as-Code-compatible way.
This sentence is a little obscure for me. What do you mean by it?
Regarding this, I believe @PWI is referring to when you create a new Grist document, it automatically creates three default columns A, B and C.
Thanks, I see. Is it not possible to create an empty table, maybe via the API?
Asking myself, why is there no Terraform Provider for the Grist API, yet?
Their code generation framework is quite comfortable and we already have the OpenAPI schema here. Could be nice to orchestrate a Grist instance from an OpenTofu project, very much like we do with GitLab and other softwares. Terraform is not just for âInfrastructureâ in the Compute/Memory/Networking/Storage sense, but for any API-driven service, Grist no excuse. How comfortable would that be.
This sentence is a little obscure for me. What do you mean by it?
I performed the test with the web API more manually. Therefore, I created the table I wanted to clone by hand beforehand. Thatâs fine for a small test.
However, I donât think that create table api can create an empty table either.
Greets
Philip