Re: "In non filemaker terms this would be where you have a front end and the database backend"
Why not use this approach anyhow, which in FM terms is usually called the data separation model.
The other way to do this, if you can take the databases offline occasionally for a short time, is to improve one copy of it, then clone that copy (so, no records).
Now import the records from the unimproved copies into the improved clone. This can be done relatively quickly, so the other databases need only be down for maybe 10 minutes before you upload the improved version of each of the other databases. One hitch: you should take the clone and set up all the Manage Security tasks while it's still at the clone stage, so that the file is fully functional when it gets back online.
We have electronic notebooks set up this way. I often come up with ways to streamline my own notebook, and every half year or so update other users' files if I've made enough changes to warrant the change. If the changes are small and can easily be copied from one DB to another, I'll do that when I can (like I copied a popover button to the other databases last week); Some of the changes to layouts are harder to just copy over. One critical point: have a 'master' file, the one you make all the improvements to, and then propagate the changes to the other files; otherwise things can get very confused.
there is no 'direct', native connection to subversion since scripts, functions, etc. are stored inside FileMaker. FMDiff does nothing but comparing/analyzing two FileMaker solutions - fast (love FMDiff/FMVis, although it's not an analyzer like CrossCheck, Inspector, BaseElements,). FMDiff can be used for tracking changes - but not in the same way as subversion/sccs.
there are 2 different tasks:
- deploying instances of the same solution on one server
- updating a solution that is in use
IF You are deploying a solution to individual servers, the data separation model will help a lot (more: It is the solution for the needs). You can create an updated version of the interface and replace it within a minute (mostly less..) - but You have to disconnect the users (unless You are running FMS14 in a 'tandem' install where users will be reconnected automatically - untested, but could be usefull here..)
IF You have to run several identical but independent instances of the same solution (data..) on one server, there is no native way - but several workarounds (Yes - one could create a method that simulates 'form pop'/'form push' with the help of SQL - but that's not the concept of FileMaker).
The other way that is not mentioned yet is to create a multi-tenant file: let all the groups use the same solution and segregate their data.
Bottom line: you are going to have to do some work, either by scripting that segregation of data in one file, or by moving schema elements around between files.
The data separation model will not solve your problem if you are creating new fields, tables and relationship, it would only be for changing the interface.
I have a similar problem as yours. I keep a master on my computer that I make all changes on.
When I update the solution I upload the master to the server, I take down the files and have scripts that clear out the Master data and then import and save the file back to the server.
Yes, if you create the appropriate scripts from the start to support this, the updating is relatively quick.
In one solution I just program in de production environment, that monster was conceived in 2004. It does mean the user does the final testing, and some things can only be programmed outside office hours.. :-(
+1 for Wim again.
Keeping multiple copies of the same solution just to handle different user data sets is going to rapidly become a maintenance nightmare.
Design for multi tenant.
You can accomplish restricting your users by group using FileMaker security using record level security. Richard Carlton has an excellent video on this topic . . . 'Record level security'.
If you have defined groups say A, B, C. Make a field called 'usergroup' and tag each user with A for all users in that group. Then make a field in the records you want to restrict, call it 'recordgroup' and enter A in all records accessible by that group.
Then in FM security set up a privilege set A and drill down to custom privileges and using get account privilege set A, use a calculation restrict the user to view only records where the user account privilege set A equals the groupTag A.
When the user logs in you can figure out which privilege set he/she belongs to and show only those records in the group.This allows you to have any number of groups in a single file.