Hi all. So very new to Glide but I think I’m making progress. But I do have a questions about version control and backup which I hope will make sense. FYI, I’m presently using the free version.
If people are using the app and I want to play around and make changes, I would rather NOT do that in the live version that people are using. I get that I can make a copy of the app and I assume it would be best to say don’t copy the tables but link to existing tables? But if I make changes in the copy and now want that version to be the new version, how do I actually go about that? Can I publish to the same “address” and it will overwrite old version and the upgrade be seamless to users? Or what is the best practice?
I know I can make a backup of the table data by saving them as CSVs but how would I go about making a backup of the files uploaded (documents, images, etc).
It is my understanding (and happy to be corrected) but if you make a copy of your App but link to existing tables any changes you make will appear in the ‘Live’ version that users are seeing.
IMO you need to create a copy of the app and related tables. Make your mods/tests in the copied version, then publish and point your users to that new version…
As far as I am aware there is no way to backup (for roll back purposes to a specific date) outside of making copies of the app and related tables.
If this is correct I’d be stoked to hear of alternate back up and rollback options.
Glide doesn’t provide any proper version control, but there are various strategies that you can adopt when making changes. Here are a few ideas, in no particular order.
Enable manual publishing
– I would recommend doing this in every App. It allows you to make layout changes and only apply them when you are satisfied that they are working correctly. Be aware though that manual publishing has no effect on Data Editor changes. That is, when you add/change/remove columns in the Data Editor, the changes will be reflected immediately in the published App
Use visibility conditions to hide new work
– If you’re building a whole new tab or set of screens, one approach you can take is to apply visibility conditions such that the new tab/screen is only visible to you. Then once you are ready to expose the new work to your users, you simply remove the visibility conditions.
Make large changes is a backup copy, and then replace the original
– This is a good approach when you are making large changes that could cause your App to be in a broken state for some period. Whether you use linked tables or a copy depends. I usually use linked tables so that I don’t lose any data edits (data added/removed by users while I am making the changes). When working with linked tables the important thing to be aware of is that non-computed columns will stay in sync across both Apps, but computed columns will not. So for example if you add a math column or a relation (both computed columns) in your copy, you won’t see those columns appear in the original. And conversely, if you add a Basic Text or Image column (both non-computed columns) in a linked table in either App, then you will see that column appear in the other App. This also applies to User Specific Columns, which are non-computed. When you are ready to replace your original App with the new copy, all you need to do is un-publish the original, and then publish the new one using the same URL.
My own general rule of thumb is that I always have manual publishing enabled, I will make minor changes in the live App and publish once done. And for very large changes I will make those in a copy, and then replace the original when done.
Thanks for this info. I will look to see if I have manual publish set because that seems like a good idea. I assume I do, but I’m not sure so best to check.
So am I right in assuming that if I have a copy of the app that I’m working on and I hit publish, will it overwrite the existing location of the current live app that users are using so it is seamless for them? As in they don’t have to delete link and go to a new link? That is moreso what I’m concerned about. If we can do unlimited copies then I think I can manage my own version control but just wanted to always publish to the one location so nothing for users to do - just suddenly there will be new features. That’s why I thought I would ask before I hit publish or anything.
And do you have any idea on I can backup files uploaded (images and documents)?
Auto publishing is the default, so you won’t have manual publishing unless you’ve explicitly enabled it.
Each App has a unique URL (which you can modify). So to get as seamless as possible experience for your users you must ensure that when you replace the App you use the same URL. And because the URL must be unique, you need to un-publish the original first - which will make the URL available, then publish your new one using the same URL.
If you are just pushing changes via manual publishing, these will usually be reflected within about 20-30 mins. If you want to ensure your users get the changes as soon as possible, you can advise them to restart the App (no need to reinstall).
Hmm… so where exactly do I find the setting for manual publish? It isn’t in settings. EDIT. I found it but it isn’t available to me in the Free version.
I will have a test unpublishing the current version and publishing the new version ensuring the URL stays the same. Thanks for all this information.
oh wow, you’re right. I’d always assumed that was available on all plans.
Sorry, I missed this earlier.
No easy way, and certainly not on the free plan.
But how important is that? Glide storage is pretty reliable, I’ve never heard of anything going missing.
One of the premises of Glide is that it offers as much as possible out of the box: building, security, login/authentication, design, on-going maintenance, hosting, storage, etc. So really it’s not in the ethos of Glide to allow you to export the source code of your projects or host your own app or do a backup of your own assets. I believe that’s why it’s not offered (yet).
I agree with Darren, Glide storage seems reliable.
In most of my projects, I create 4 folders as follows:
One folder with the published app
Two folders which I call “Backups”, one where the tables are synced and the other where the tables are not synced. Anytime I am going to make majors changes to the live published version, I make two backups. I’m totally paranoid, I trust myself to mess up the live app, so these are a protection against myself. The title of the projects have the date and time of each backup.
And in between I have a folder where I or the customer can play around or test things.
It doesn’t happen too often, but I’ve had cases where I have had to use a backup. I used to not be too diligent about if the tables where synced or not, I used to mainly do backups with a table sync. Now I’m religious about doing 2 backups every single time, synced and non-synced. I had a case where a made a backup one day (with table sync only) and the very next day the client contacted me asking if we could use the latest backup because he had totally messed up rows and rows of data in one of the tables. Lesson learned
Thanks. I will still backup tables but it does make me nervous about not being able to backup the uploaded content and im surprised there is no option to do this.
