So… Simple question. I must be overlooking what must/should be glaringly on the product label. OttoDeploy/OttoFMS migration terminology, etc, is the OPPOSITE of FileMaker Data Migration? Correct?
In other words, OttoXXXx is not designed to “migrate” data from one file to another. Instead, an OttoXXXx “Migrate” replaces the stuff that is NOT data.
Therefore, if I want to refresh a development file with production data, I should use Claris’s command line data migration tool. That is, assuming I don’t have a “Development”, “Staging”, “Production” setup as shown in the complex deployment how-to video.
Have I got this right? Is this simple thing obvious to other new users? Where is it made clear in the marketing and/or documentation? Because, FYI, I totally didn’t get it and wiped out some development work the first time I did a migration.
Other than that little/huge misunderstanding, I adore OttoXXXx versus Otto/Migrator.
So sorry you lost some Dev work. We take that sort of thing seriously so we spent some time talking about the mixup here and we think we understand how you came to your conclusion. We are going to try to improve the User interface to make it clearer what is happening.
The thing we didn’t make clear and we will make more clear in the next version is that in Otto Deploy DATA always comes from the Destination Server, and Schema always comes from the Source server. OttoDeploy does not let you switch those two. You can’t make the destination server the source of the schema, and the source server the source of the data.
Technically the API that backs all this running on OttoFMS can switch the two, but we thought that adding that option to the user interface would be harder to support. So we simplified it. But maybe we can figure out something in the future.
But for now you can accomplish what you want, which is to refresh your dev file with production data in two ways.
After you do your next Dev to Prod deployment, use a second Deployment to copy that Prod file back to Dev. This is pretty easy and what people do to day with Otto 3. It does require making two deployments.
You can setup a single deployment with three sub-deployments, similar to the advanced deployment video you mentioned.
Sub-deployment 1 will Install/Replace Prod to Dev with a name like MyAppPROD.
Sub-deployment 2 will migrate data from myAppPROD into your MyAppDev file.
Sub-deployment 3 would just replace MyAppDev with MyAppProd
That may seem complex but it is pretty easy to setup with the Advanced Options, and it won’t be any slower than they way you thought it should work.
We will make changes to the User Interface and add some docs to explain what I just did above. We hope that makes things clear.
But (and I do it now) the ‘Destination’ can be a different file on the same server. The Destination is the source of data for a cloned copy of the Source file.
Presume this is not going to change??
I think it helps if you think of it a deployment as having two Server Roles. Source and Destination. But the roles can be played by the same server.
So yes the destination file can be a different file on the same server that is playing the role of Source. But that is because the Source Server is also playing the role of Destination
Just dropping a note here to let ya’ll know I’ve been blocked by apparent SSL certificate issues as discussed in the other topic here “All Migrations Fail”. Prior to that, I was going the route @toddgeist suggested. Once we’re able to get OttoFMS/Deploy working again, I’ll get back to doing a simplest possible implementation of a pseudo dev/stage/prod deployment strategy.
