Hey all, I’m pretty confused on how everyone is doing dev safely without breaking their live app. I had asked this question but only person who responded is in the same boat so presumably nobody has figured out yet… Would be great for someone from Adalo to comment here. This video below shows what I’ve attempted to do via the copy feature in the app:
Ideally there would be a way to safely clone the app (database and all), work on the sandboxed version then migrate changes back into the live app. I do like that I have the option to either copy the db so it’s completely separate or reference it directly from the sandboxed instance, but that doesn’t work in practice. It just duplicates the schema, not the data. Or when you reference it, it seemingly uses the same URL so how is it even a sandbox at that point? I would think a more desirable behavior would be to duplicate the entire db on copy including data then give me the option as admin to wipe all the data if and only if I don’t want it.
Is anyone successfully using the copy feature in their workflow here or is everyone cowboy coding on the live instance? If the latter, what techniques are you using to mitigate risk of hosing your production app while you’re doing dev? I’m having to do things like create a “.” in the corner of the screen that links to the new screen to pass the data through but minimally noticeable to users of the production app. Feels super kludgy and obv experimenting with schema changes in this scenario isn’t possible. We don’t have a ton of traffic (yet) but this is soon going to be a big concern once we have any significant amount of traffic.
For Adalo: this topic ^^ would be a great webinar to do even if the workflow isn’t ideal now: just practical tips on how people are dealing with this now. Highly recommend looking at Pantheon’s dev workflows with WordPress to see their process for this - it’s backed by Git so feels bulletproof and trustworthy and gives me peace of mind if I ever hose things I can always roll it back. If I could wave a magic wand I would love their Git-based visual dev workflows only for Adalo. TIA
The method you suggested of creating new versions of screens that are not visible to the normal user flow while you’re developing/testing is generally the method I use. Sometimes as a first step, I’ll spin up a new app to test out a concept if it’s something I’ve not tried before. Also, as a best practice, I try to release changes in as small of iterations as possible and then test before moving on to the next change.
Definitely agree that that’s not ideal, and as people continue to develop more complex apps, the need for developing a true version systems within Adalo is more pressing.
@charitymakerover You are one of the pioneer Makers with Adalo. Not many of us have live apps in the wild, and even fewer have useful apps with active and growing user bases (at least ones announced publicly).
It’s going to be hard for the Adalo team to manage; on the one hand they just launched and haven’t come close to owning the market for no-code development. So they need to add features fast and furiously. On the other hand, as the Pro tier grows, there will be more people like you in a development bottleneck who can’t update their apps efficiently. The versioning problem will actually be a good one to have! It will prove the success of their core proposition: building and launching apps quickly.
IMHO, the time may not be right for Adalo to focus scarce engineering resources on the needs of agency builders (indeed a different level of Pro user, more like a Power user). But I’m going to bookmark this!
Would be great if one of the makers of the apps showcased on the Adalo website could chime in here as to how they continually develop/update their apps (Salman of Tavolo, Ryan of Chant, or Jay of 24 Hour Designs).
Well said @tdhi
Agreed Adalo likely has bigger fish to fry for now but I think meta projects like the component marketplace will enable an “App Store” of sorts which will start to leverage the community’s power to solve (and monetize) their problems for them. Versioning and having a sane development/ deployment workflow is something more fundamental to the platform though that even with a component marketplace only they can solve.
I am very curious to hear from the other power users you listed as to how they’re addressing this issue currently. I don’t even have a native mobile app for us yet so that’s a whole other layer of complexity we’re not even tackling right now…
anyways thank you for your thoughtful reply and hopefully we can get some insight from the others who have already found adequate solutions to deal with this issue today sans a proper versioning system.
Having a sandbox version is critical to app development and should be a standard platform feature. I think it’s far more critical than a marketplace. (EG: What if we purchase a feature/extension from the marketplace and not have a testing environment to check if it works? It can break your app)
A simple solution is no changes occur in the live app until you hit re-publish, and use the preview function for testing.
I am looking at Adalo for re-building my current web and mobile app which has 10K users (not concurrently of course) so I am in the same pickle as you, trying to work out how to dev in a sandbox.
I am thinking of doing an app copy with database and manually uploading non user related data from the downloaded CSV (IE categories, types etc) and just have some dummy records in the other collections in the sandbox DB.
BUT, if I change any fields in the collections, I will need a way to replicate that to the “live” app and copy the screens across after testing.
I don’t want to use copy with same database, because any testing data will show in the live database.
@Schelle I agree this is a super important feature but just to put things in perspective, Adalo is a startup confronted with all the challenges of a startup juggling 1000 priorities. I agree this is up there high in importance especially for anyone who has existing users and user-generated content.
Ideally a stopgap would at least be to make it so cloning the database brings over the data by default and gives you the option to wipe it instead of the current scenario where you have to export/import each collection as a CSV manually. That would be a quick win for them to fix.
The best advice for now AFAIK is for small tweaks just develop live on the production app. For more structural changes, clone the app, make changes on the dev instance and keep track of what you did there then port those selectively back into the live app. That or go the other direction and cutover your prod URL to the dev app and bring across the data from the old prod app to the new prod app. Either way there’s going to be manual work and room for error now with the current tooling. Price of having all the other agility benefits for now I guess… This is still a net win agility-wise vs. developing with code.
