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

Request For Comments
#12

This is going to be a though and critical one. One thing is thinking you are going to be more or less productive having a SC in a tab and complete different thing is having to change deployment workflows.

My suggestion is:
a) Start from scratch. New files for this.
b) Mark it as experimental for as long as needed. Even if it takes 6 months.
c) Leave current functionality as-is. UI and code wise.
d) All new panel in a tab separated from the old UI.
e) Iterate progressively until the current deployment workflows being used are covered and your new deployment framework(and servers/services reimagining) and UI is flexible enough to keep adding/changing in the future.
f) Switch off old UI/logic.

#13

I have not had much issues with current Wappler target settings - apart from the fact that DB connections gets messed up when setting up or switching between targets - even more so with Docker.
Usually, I set it up once, and forget about it.

The integration with Git and versioning and all sounds like an “advanced” type of workflow which would require docs even for things which are out of Wappler’s purview - like Git & Docker setup - and support too.
The docs right now are not very extensive on this.

As informed by Patrick in a post yesterday, the Git workflow right now is built with the idea of keeping things simple with some advanced stuff. It will NOT replace powerful tools like SourceTree etc.
So, I am not entirely sure how the idea here is going to take shape.

The main concern I have is there are as many deployment workflows as there are developers, which then gets complicated by number of server models.
I like the idea of a more mature target settings & deployment workflow management from Wappler, as it matures with more features.

I do like Jonas’ suggestions to take things slow in this regard, but not sure how slow would be good enough.

#14

Do you use Wappler’s DB manager for this?

#15

Yes. I do modify the migrations file by hand for some advance schema features that are not available from the UI.

But the act of applying and reverting schema changes I do it from wappler’s db manager.

Ideally I would run automatically those migration files from my CI/CD pipeline but I haven’t got to that yet.

Maybe I won’t have to worry about that if Wappler offers a powerful and flexible CI/CD solution in this new iteration of targets and deployment.

1 Like
#16

Will probably have to trouble you someday to understand this. In my experience, the DB manager has been unusable. DB migration is something I learned about when trying out Laravel, but haven’t been able to use it yet.

1 Like
#17

As long as I can still use my MAMP Pro as my development target and I can still choose a single file to upload to production without having to do a full deploy. Quite often I am working on my dashboard on MAMP Pro development target but make a small change to a page I need to be able to upload that single file without deploying unfinished work.

#18

I think this is essential and needed frequently as you say. Eg today, I had to search a new site for the word ‘delivery’ and replace it with ‘shipping’. This affected several files which I uploaded in a minute or so. Later, while on the phone to the client, I made a few similar changes. Redeploying a whole site in such cases would be extremely inefficient, and potentially cause all sorts of problems.

2 Likes
#19

Which is why I usually keep an FTP client like FileZilla running while working on changes in one file or more. I always need to know what I’m targeting on uploads for small but significant changes.

Sometimes I run the same application referring to the same database in another “private” folder which I want to check in the online browser without “panicking” the client if the main application is in use online.

I’d rather not have to “bother Wappler” with a whole new target setup for this reason.

#20

I also use FileZilla in parallel with Wappler, but less so now that Wappler’s upload features have improved and I’m more confident that Wappler won’t upload files I don’t want uploaded. I also use it because Wappler’s File Manager is rather basic. Eg I might want to upload a set of recently edited files - but Wappler has no way of sorting files.

#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?