Wappler 4 RFC: Rethinking of the deployment workflow and target settings

Request For Comments
#21

I personally do not use local testing as I am continually swapping between laptop and desktop (at the office)
I always upload to a live sever testing environment (sub-domain) then that way I know everything is going to work on my server with no issues.
I have had instances previously when something has worked on the Mac but when its uploaded to the server it did not work.
I use Maria DB on the server and that I can’t find a way to put that on Mac.

#22

@George, your ideas sound great.

A few points from my perspective:

  1. The complexity of my app and its business means I have little time to experiment with new features any more. I’m now working on sales and marketing as well as development, so the methodologies I have created, I just need to keep with.

  2. My publishing methodology involves a power shell script which copies files from the relevant .wappler folders and then creates a zip file which I upload to Elastic Beanstalk. I know you are going to tell me this is a terrible thing to do and changes you make could break it… but it works and I have no time to investigate anything else. Git just confuses the hell out of me.
    So… I’d appreciate some warnings if you plan to change the underlying .wappler file structure.

  3. I tried to move to Docker in December and the whole experience was a nightmare, and I never got it to work. There is a trail of problems reported on some threads on the forum. Anything you can do to help others avoid those problems in the future would be great.

Thanks for wanting to consult with us! :slightly_smiling_face:
Antony.

Custom Deploy button
#23

We never develop locally, as this makes simply no sense at all.

The reason for this:

  1. we want to develop on the same server configurations as the hosting provider provides. Some features can’t be tested locally at all. We will not build our own servers for developping. It’s simply the wrong way to go.

  2. Multiple people are working on the same projects.

What we really need is a batch uploader/(downloader), means the possibility to update multiple projects in the same task, as we use the same cms for all of our project. So it would be great to have the possibilities to define for example which folders have to be uploaded and then select the projects/targets. And with one click all uploads to all of the projects take place. THIS would really help a lot.

Also having a Wappler AppConnect js-file version checker which shows what current *.js are the newest and what are currently used in a project. With this list, also to have the possibility to update the projects with the newest files. This currently runs in the background when you save a .php page with extension on it, or by saving a server action. But this never covers all of the files being used. So the projects are never 100% up-to-date.

#24

Development target doesn’t have to be local as long as it is separate from your live customer target.

I presume you are not working directly on your live customer site during development?

#25

Don’t you guys use a remote GIT repository to sync and develop locally on each developer computer?

I would have thought a web design company with several developers would have relied on a CVS for that as it’s considered industry standard and best practice. And then use remote staging environments for clients to test if needed.

Curious to hear why this approach is not practical for you guys.

#26

I presume you are not working directly on your live customer site during development?

We have test-hostings like dev.customer.com where we implement new features and test.

#27

The ideas are great. As a Full Stack developer student and ex Bubble user, I think that better deployment options is a great idea for Wappler 4.

For newbies like me, controlling the versions you can deploy to your production target is very useful when encountering problems after updating your code.

I would get inspiration on Bubble’s deployment features where you can manage the different versions of your app depending on each target.

2 Likes
#28

When I have the opportunity to test from the very beginning on the actual platform where the application will reside when completed I always test in a separate folder that has the same server globals and I can connect to the account’s database.

But keeping local environments on my own local server that match as closely as possible to the intended remote server sure saves time.

It’s also useful for inevitable “How come it works here (proven standard setup) but not there?” problem solving.

#29

Git is hard: screwing up is easy, and figuring out how to fix your mistakes is f**king impossible

2 Likes
#30

Yes, I went through it once, and my reaction was “Never again”!

#31

If the development target isn’t local, is that going to cause issues with custom queries in SC for Node?

Is there a way around it?