Test database and production database

I saw this though, I’m still wondering how I can solve my situation.

What I would like to do is:

I want to have DBs in production and developing environment.
I want to implement dev version with test db (one of them mentioned above).
I want to push tested part to the production but this production should be connected with production db.

How can I do this?

two ways to achieve this:

1
single code base: you can keep a single code base (one Wappler project) and change the DB connection strings and other variables when you want to publish projects between DEV & PROD.
this is suggested method when you have steady hands - you won’t publish the project incorrectly between the servers.
to make switching easier, you may make a list of strings that you need to find+replace & save it in a notepad.

2
separate code base: this is my preferred way (coz am clumsy!). have 2 separate code base (2 Wappler projects - one each for dev & prod). this is rather simple but time consuming as you have to continuously update both projects every time.

we started with a single project and when it was time to go prod, we created a copy for production to keep the clear distinction. our project does not need huge changes frequently - so this method works for us just fine.

1 Like

Hi Miwa,

I go with GitHub and a little one time setup in the beginning.

I have only one target—dev
When ready for production, push to github
Then ssh to production server and pull from GitHub.

Easy and simple and two different behaviors For dev and production so no inadvertent production pushes.

The db connection however is added to gitignore so it does not update production. When setting up production, manually update the db connection file to match its needs and then never think about it again.

4 Likes

Thank you so much @nshkrsh and @mebeingken. I’ll look into details from your tips. I started using Docker, so anyway I keep developing my service under dev environment first!!

I like your solution, @mebeingken, but it’s still not quite doing it for me. I now work consistently on three machines - an iMac at the office, an iMac at home and a Macbook Pro. I am using Github to keep everything in sync - I commit and push at the end of each session or multiple times as I complete tasks on the project. Then, when I start on another machine I pull the changes. This works brilliantly but relies on everything being committed including the file containing the database connection details. I’ve put in a feature request for this file to be split - one file with the login details and another with the schema - so I’m hoping they can implement that. I still would like the database details to be stored at target level because having to change them every time I switch targets is a real pain and is bound to lead to mistakes. I launched a site last weekend and am still working on it so switching between targets is happening much more frequently now.

1 Like

Jon, I haven’t tried this yet, but it might work for you…

https://git-scm.com/docs/git-update-index#_skip_worktree_bit

Thanks Ken. I’ll have a look at that but am really holding out for a change in Wappler to allow for much easier multi-target projects.

The challenge here is not only multi target configuration, but also having global config settings per project that you want to switch as well.

Not only you want dev & production database connections - but also as Ken pointed out you might also have a dev and production API/Server Connect.

Usually such configurations are handled by environment variables, and this can be done indeed server side, but for the client side is a different area. There indeed App Connect might help with global variables and having there different settings store like API urls, endpoints and more.

Thanks @George. How about splitting that up? Basically, I want everything to be identical apart from the FTP settings and the database connection. The FTP is already stored in the target settings, could the database connection be moved there, too? The schema and everything would be shared across all targets.

If that’s not possible, could you just split the contents of the /dmxConnect/modules/Connections/connProjectName.php so the connectionString is in a file on its own and the rest stays where it is? If the connectionString could be in the target settings then that would be perfect. Splitting this out would also mean I could make sure the connectionString file is in the .gitignore file so doesn’t ever get pushed to Github.

Does that make sense?

In the old days of Dreamweaver, I would upload the connections folder and leave it alone. I would only change it if the database details changed. That’s something I really miss with Wappler.

1 Like

Yes we will be moving the database settings per target as well.

Much like we already did with docker targets. Then when you switch target you get the right db connection for that target.

It is just that there are also other project settings that need to be per target .

Also we want to distinguish the targets as “development” and “production” type target.

So we can safely upload new files and stuff to development targets, but on production you have to manually choose to “deploy” the whole project. Which will result in synchronization. So that no production files are overwritten while you don’t want.

We already have those settings in the projects settings per target - they just don’t do much yet.

1 Like

That would be awesome and make like a whole lot easier. Huge thanks.

Could you make sure the database connection details (even just the password) is in a separate file so it can be ignored by Github?

This has been Implemented in Wappler 2.7.0
Now you can define different db connections per target.