I realize the provided solution to scheduling isn't hugely complex ... but after so many other leaps of convenience afforded by 360Deploy,  the current procedure for setting up a scheduled run does feel a bit... chunky. Hope the next release includes a nicer front-end approach to specifying a migration time and push-click-done.

Meanwhile, can you clarify the instructions from your wiki:

Quote

The script "Upload Files and Start Migration ( $~configuration_id )" is Server Side compatible, and can be used in a Server Side Schedule, which is our recommended way of doing a scheduled deployment. To use this script, we recommend creating a wrapper script, where you can pass in the id of the configuration to the "Upload Files and Start Migration" script.

Does this mean I should host the 360Deploy.fmp12 file on my dev server to make that script available to it to run on a schedule? Or are you suggesting I copy the scripts into my solution?

- - - - - 

Also can you provide more guidance on the pros and cons of running 360Deploy on a workstation vs on the local dev server vs on the remote prod server? My lightweight testing so far makes it seem like executing from my workstation is plenty speedy and convenient and doesn't require any remote screenshares and doesn't require launching FMP app on those remote machines - all plusses in my book.

Finally, f I want to manipulate the migration task manually from more than one place (workstation 1 vs workstation 2) are there considerations?

Edited February 20, 20196 yr by MMHinSEA

Hey MMHinSEA,

I will update the documentation to make this clearer, but if you want to schedule deployments, we recommend you host the 360Deploy database on your Dev server, and schedule the migration using the FileMaker script scheduler, which will allow you to pinpoint an exact date and time you want the migration to run.  In my own setup, 360Deploy is hosted on my dev server, and I open the file remotely to manage and trigger deployments.  With the file open remotely, I don't need to remote into a workstation to open the file.  

As to the pros and cons, I prefer having my file hosted on a dev server so I can take advantage of the features of FileMaker Server (backups, server side scripts, etc).  In the end, there is little difference when actually using the file, and if you have a strong preference to keep the file local it should work fine.

If you want to manage the 360Deploy file from multiple computers, having it hosted on your dev server will help with this as well.

Thanks,

Joe Martin

 

Hi Joe - that's super clear and the kind of direction I had been looking for in the documentation. Thanks very much. 

I have a quick question re using the 360Deploy ( hosted on my dev server). I was going to use the script wrapper PSOS : 360Store Deployment to pass the Config ID to the "Upload Files and Start Migration ( $~configuration_id )"  script  but Is there a reason it has the PSOS step 3 times?

Perform Script on Server [ Specified: From list ; “Upload Files and Start Migrations ( $~configuration_id )” ; Parameter: #( "$~configuration_id" ; $~configuration_id ) ; Wait for completion: Off ]

Perform Script on Server [ Specified: From list ; “Upload Files and Start Migrations ( $~configuration_id )” ; Parameter: #( "$~configuration_id" ; $~configuration_id ) ; Wait for completion: Off ]

Perform Script on Server [ Specified: From list ; “Upload Files and Start Migrations ( $~configuration_id )” ; Parameter: #( "$~configuration_id" ; $~configuration_id ) ; Wait for completion: Off ]