I'm just wondering what is considered best practice here.
A typical scenario which I am familiar with might be to have a 'dev' environment and a production environment. The code gets from dev to production by some publishing mechanism. The only difference is that on production a flag is set in a config file to say that it is on production. (This file is not published). Ok. So there are millions of ways to do this - and it may involve a staging server etc. etc. But, in general, how do people approach this with CS-Cart?
Because there is a database involved it can't just be a question of transferring files from the file system from dev to production. (Of course the database file itself could just be mirrored but I doubt this is the way to do it).
Basically - I'd like to have a development environment and a production environment (and optionally a staging environment). What is the best way to achieve this with CS-Cart?
You could run a version of your store locally on your local desktop workstation or have spare webserver account. You can lock the webserver account to one specific IP making the server only available to your IP.
There is plenty to find on how to do both here on the community forum and in the docs.
We run our own dedicated bare metal xen server which hosts 4 vritual machines, 1 Cpanel production CentOS linux server, 1 Windows 2012R2 server for Coldfusion CFML legacy store and development and 2 Cpanel servers for sale.
I have two development store running in directories of the live production store myself.
This topic has been discussed a lot. Doing a search will reveal a lot of good discussion, history and examples.
There is no out of the box dev->publish->production process and it was not designed into the standard product.
That doesn't mean it wouldn't be possible to develop and distribute such a development/test strategy. The problem is that no one is interested in paying for the development and given the frequency of cs-cart updates and changes to DB schema, it would be prohibitively expensive to maintain from release to release. Cs-cart themselves has trouble maintaining store import (or releasing it in a timely manner) and this is their product!
We setup development environments for our clients all the time whereby they can experiment without impacting their production sites and where we can do custom development and they can verify before being applied to their production site. We provide tools (shell based) for cloning their current version and DB and then sync back any custom changes we've made or re-clone it after their experimentation is done or when they want to play with something different. Turns out to work well for doing things like testing a new import, making changes to product features and a variety of other "mass changes" that you might want to verify before applying them to your production store.
As others have mentioned, you can do another account on the same server as production, a local install using Windows (ie, WAMP server), or some flavor of Linux with a standard stack either on hardware or as a virtual machine (ie virtualbox). Everything would be pretty standard except for a couple of extremely annoying issues that force devs to dabble on the edge of terms of use:
1) There is no longer a CS-Cart "Free License" so your dev env needs some quoteunquote "repairs" to allow unlimited use. Note that these changes need to persist when you sync from the live store and be ignored when you sync to the live store.
2) Addons and themes such as those from Energo also need some "repairs" in order to work on another server/ip (this is due to devs not allowing development instances to use same license as live store <-- this is insane mentality for year 2017). Same rules for sync apply.
As far as server goes, We use a a few Vultr instances for development. Reason being is that they are very cheap for the power, extremely fast, and have snapshots. This means that you can instantly take a backup of the entire server to restore to later. This works excellent when trying things out which may wreck the store, new addons, new themes, etc. In addition to a development license of WHM/cPanel so you can try out different builds, new server modules, dry run upgrades, etc without liability to production. Note that if you apply for WHM dev, you need a static IP. https://cpanel.com/developer-license-app/
It was initially hard to decide between Ramnode, Vultr or Digital Ocean, but Vultr won and we never looked back. A bunch of colleagues use them too for production instead of just dev (100% uptime guarantee). In addition if your production is on same vultr account as dev, you can share snapshots-as-deploy-image between the servers. Easy peasy. http://www.vultr.com/?ref=7089010