Enhance resiliency of target switching

[Apple]

Enhance resiliency of target switching

When I’m developing and want to deploy to Production, I switch to Production and Deploy, but often forget to return back to Development target.

The issue is, I go to the browser to load localhost, and it attempts to connect to the Production database, because the selected target is Production.

It’s my belief the target switching functionality is far from ideal, as there might be a timeframe where the Development server tries to connect to a Production database. Now, imagine (e.g.) about scheduled actions of Development running on a Production database…

I suggest to enhance things in a way that production DB credentials don’t end being used by the development target, don’t ever mix target configuration

My stack: NodeJS Docker

[Cheese]

Would be nice to be able to disable scheduled Actions from running locally (especially when using a remote DB).

[sid]

@Cheese

disable scheduled Actions from running locally

Its a manual setup, but you can already do it via ENV variables.

Set Debug & Scheduler Options Via $_ENV

Hi. Deploying our apps via Git using Caprover is a great workflow. One thing I often miss is the option of having target based settings. Most of them have been replaced by ENV variables, but there are still a few remaining - like the config.json file. Does the config file support setting up values like “debug” or “cron” etc via ENV? I do remember reading about a user config file as well, but not sure if that is the solution here. Please help.

[sid]

@Apple

When I’m developing and want to deploy to Production, I switch to Production and Deploy, but often forget to return back to Development target.

Are you sure you’re not just getting old?

When I used to use Wappler for Docker deployment, I had a similar problem. But not very often. And because I had different data on the homepage, I would immediately identify that I am prod target.

Still waiting on @Teodor to release doc on deploying multiple Docker apps on same server via Wappler to use resource manager again… but until then, Caprover & Git based deployment works great.

[Apple]

@sid

Are you sure you’re not just getting old?

I think it’s just bad UX In fact, in a high-code development situation, people just run a command to deploy or Git Push, and don’t ever worry about changing targets. They use 1 click when Wapplers use 2 clicks

I’ve been testing Wappler’s Docker deployment lately, I opened a lot of bug reports/feature requests around that (luckily, they fixed things pretty quickly). Hope they do the documentation you’re looking for. I’m not doing things the Wappler way, I don’t trust their configs yet, I deployed Traefik on my own using Portainer, and then added Traefik labels to docker-compose of the Wappler app (production target)

[Teodor]

@Apple

I’m not doing things the Wappler way, I don’t trust their configs yet,

Can you maybe share some more details maybe in a separate topic, so that we can improve this?

[George]

I couldn’t agree more!

We are actually in process of migrating away from the targets switch. We just have to do it gradually as many people are used to it.

Our first step was already making “Publishing” possibility - where in one dialog you can just publish to your live production target, without the need to switch.

Next steps is to enhance the target dependent editing of global things like Database Connections and other global settings.

We are already prohibiting editing of many actions like database and server connect settings on other targets than development.

So slowly, step by step, we are getting there