Development and Production environments?

[Slowfib]

Does anyone have any advice on how they setup and manage development and production environments?

How do you push your changes to production from dev without overwriting data or corrupting scripts?

We do a lot of PHP integration as well, so the way we've been dealing with everything is we make our changes to production, copy the production files and then rename them as testing files. Then we can create all the testing data we want.

Can anyone recommend any good articles on how I should better deal with this? Are there way to copy scripts, layout and table structures?

Thanks.

[Vaughan]

This is where FMP's single file (data and interface) works against it.

Somebody will suggest the separation model -- that's only helpful if only the interface changes and the data stays the same.

The only way is to import the data. Automate the process using scripts to pull data into the correct tables and reset serial numbers. Remember to keep the import scripts up to date.

[Fitch]

RefreshFM makes this pretty painless.

[jbante]

I think there's a more interesting problem here than what the proposed solutions are addressing. Swapping a UAT file for a production file is one thing; updating functionality with zero service interruption is a different beast, but a beast worth taming. Recently, I find myself working on a system that is very sensitive to service interruptions; taking a file down, transferring data, and uploading a new version is not an option. Nevertheless, updates have to happen. It's not the poster child of a robust business process, but I don't get to make all the choices. (The whole world would run so much more smoothly if I could just rule it.) I have to devise detailed transfer and rollback protocols for any updates to existing functionality — copy this custom function and that table and this layout and that script in this order, and install rollback switches between old and new behaviors here and here and there, etc. The abilities to import scripts and custom functions and to copy/paste tables and fields are invaluable, but it's still a largely manual process.

The need to transfer code has some effects on how I develop: I find myself building parallel copies of scripts and layouts, rather than modify existing ones, because it makes it easier to import/copy/paste, and because it exactly preserves old code in case there has to be a rollback. This also means I have to maintain a deprecation protocol, for when the new functionality is proven adequately reliable. It's more work, but you don't get to eat your cake and have it, too.