You can now control whether Glide automatically publishes your app, as well as revert your changes to the last published version.
Toggle this through the Share button.
You can now control whether Glide automatically publishes your app, as well as revert your changes to the last published version.
Toggle this through the Share button.
Wow, this is absolutely AMAZING!!
I remember asking for this last year. So happy to see it’s finally here!
Engineering team this is what a exciting and powerful update, absolutely fantastic!!! Thank you……
Question @Jeremy
Only available in Pro apps?
Yes
Hi All, Could someone please give an overview or the Do’s and Dont’s of the feature?
I know it is quite obvious. But, documentation would be beneficial.
DO publish your app when you are comfortable that everything is working properly.
DO revert your changes if you feel you did irreparable damage to the app.
DON’T publish if the app doesn’t work yet or you don’t want users to see changes
DON’T make data changes that could affect the live app.
thank you! This is great news
Is publishing only for components or does it include data? I mean I have switched off Auto Publish. Then I change the data. Does the data sync? or is it only for component-related changes?
Your data still syncs.
Thanks for the Clarification David. Hope the documentation or explainer video will be out soon.
It would be nice to have a future option where the data only syncs after pushing a sync button. That would be ideal for content production.
Love it. Just so badly wanted this (there is always this hint of doubt if we broke something with our changes) and had asked about it couple of times in the past also. Thanks so much Glide team.
-Shiv
This quickly gets into the case of “I want to sync this but not that and this thing over here but not that thing over yonder.”
I’m not quite sure how to make that intuitive and understandable yet.
Well, it’s not a strange thing with content to first make it and publish it when everything is ready WordPress is big with it So is Shopify.
Wohh… This is amazing
Speaking from experience from my job, program changes and data changes are tricky. We have Dev, Test, and Prod environments. Databases are duplicated for each environment. When developing program changes that require changes to the database structure, we first change the Dev environment DB and develop in the dev environment. When going to user testing, both coding and DB changes have to happen in the test environment at the same time. Same with the production environment.
With Glide we do not have separate database environments. We only now have a sandboxed app design development environment. Only one database feeds both published and dev environments. If you start changing the database and remove columns that are used in the published production version, or start to change how computed columns work, then you start to affect the published app as well.
When making only design changes, then there shouldn’t be a problem. If you start to mess with the database without publishing the design changes at the same time, then I recommend creating new columns, develop against those new columns, then once you publish, go ahead and do some cleanup on any old columns no longer used.
As far as data content, that could easily be controlled with proper visibility and filtering to display new content on a certain date, or when a flag is set in the data.
There may be a bit of a transition process do complete a production publish, but always consider the database to be live for production and dev.