Hi, I work in life sciences…medical device industry. I used glide to build a proof of concept purchase order and inventory management app. Great platform, but have concerns about being able to validate the sofware as required by FDA. Usual validation process would be to test all changes in a sandbox/test area before they are live. That doesn’t seem possible with Glide, and the on-the-fly dev model. Anyone out there have experience with doing this in a regulated industry?
Glide does not have a true dev/test environment. They do have publishing control to be able to publish front end changes when ready, but it doesn’t allow for external user testing until published and it still uses the existing live data. The publishing control is only for front end changes. It does not apply to data table changes, which are always live and on-the-fly.
What I’ve done in the past: in the dashboard I duplicate the app with a separate copy of the table. In the dashboard the wording is “duplicate app” and “duplicate existing tables”.
In my team I set up folders as in the image below. I use the terminology “Connected” and “Separate” instead of “Linked” and “Duplicate”, but that is a detail.
For the sandbox/testing area that you suggest, I put the duplicate app in the “Tests & Drafts” folder. I rename projects carefully with dates and the nature of the tables (connected / separate).
This process might not stand the rigorous process required by the FDA, but this is how I’ve done it and still do it.
Warning: I’ve never experience it yet, but it seems that duplicating an application does not duplicate workflows with manual and webhook triggers. This might be a bug, but nonetheless it might be there (do verify this if you think you might be affected).
Edit: According to Dana, “the workflows do copy over, but they are disabled. And, I think, because they are disabled, the other workflows that use the manual ones now show a dash instead of the workflow. I go through these and reselect them.”
Thanks for the response. Once you have tested any new features, are you essentially re-doing all of the changes in the production version of the application?
2 options:
A. Either I redo all of the changes in the production version of the application.
B. Or I change the DNS records to point towards the testing app. So the testing app becomes the one in production, and the one in production can be archived.
I usually prefer option A, especially if the changes weren’t too massive. I try to build that way, with little steps. Option B can also create friction when getting another party involved.
But maybe my approach could be improved. One could see option A as a waste of time, and maybe option B would minimize risk of making mistakes when building a second time.
Thanks for your response, Jeff. This was my understanding.
Thanks. That’s an interesting option I was not aware of. I was wondering if anyone out there had figured a way out of making this possible. Very much appreciate the input.
I forgot to mention. I said you could do a DNS swap if you are using a custom domain.
But if you’re using the default Glide domain, you can also do a swap of that domain:
- Copy the subdomain of the app in production, paste it somewhere safely for a moment.
- Rename the Glide subdomain of the app in production.
- Head to the testing app.
- Passe the subdomain you were using for the app in production that you saved safely.
- Publish the testing app.
With this approach, your app in production does end up being offline a few seconds.
