MMHinSEA

Thanks Joe - appreciate it

Yes - working with FMS hosted files. Thanks for the clarification about the scripts. I must have noticed those in an early phase of playing with the file on my desktop.

Great to know! (but, argh, wish I knew before I bought the FMDS specifically to use this - oh well)_

OH! This is very interesting indeed. So do I have this straight? My Express license will permit this: (dev server) (prod server) DevFileA------------------------>ProdFileA DevFileA------------------------>RemoteDevFileA

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

Hi - thanks for replying. I do understand there are many high and low priorities as you develop the software and look forward to some clearer formatting and/or language in this window. The specific issue I screen-shotted above could probably be solved easily with a "(none)" in the space below the "completed" heading. Any kind of progress indication would be welcome. Even an indication showing if block or record based cloning was being used would be helpful. Another easy change that would provide immediately-useful feedback would be to add in the confirmation email a "Total time to complete" line near the top of the message... the start and end times are there, so that should be a trivial calculation. Thanks~

When running a migration, the messages are confusing. At first, it says the migration is complete, but the yellow dot remains yellow, then a follow up message appears, "Migration NOT complete..." along with a delay while (presumably) the migration actually progresses towards completion. Then, finally, green dot and completion. The competing messages are confusing. For a future release can these be edited to be more descriptive of the actual state of the migration process? Bonus coverage would be if the system recorded previous migration start/stop times and gave some educated guesses about time required to complete the process. The time required is quite different for different servers/solutions and the reminder would be helpful to me as I sit and wonder how long I have to wait before worrying.

Aha: confusion over where to actually get information.. - README.TXT in the app folder - "Product Documentation" at https://static.360works.com/plugins/360Deploy/documentation.html - Product Wiki at http://docs.360works.com/index.php/360Deploy They don't all have the same info. I now see my question is answered in the Wiki... Solved.

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: 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?

During migration, the 360Deploy tool is supposed to create a timestampped folder with an archive of the about-to-be replaced production file. Where is this stored? I'm searching my production server (win2012) where I've been running the demo and can't find these archives anywhere. Ability to specify a location for such archives other than default would be a nice update to the tool BTW.

In some situations, I would like to use the 360Deploy tool to send my dev file to the production server WITHOUT replacing the current production file. This remote 'dev' file on the production server would allow us to test solution performance on the client's server with live data without affecting the production solution. Then, if it were all OK, we'd run the migration normally, the way it works now. The basic license appears to only permit a single database on one pair of servers (dev and prod). Would be great if there were an accommodation to push a 2nd copy of the dev file up to the prod server, - even if it had a 360Works demo file name - for performance testing. Maybe our shop is the only one who would find this helpful--- but I suspect we're not alone in having to fine tune our dev work based on unexpected WAN gotchas. We always prefer to spot and correct those before subjecting end users to new features that are unexpectedly sluggish.

Unless I've overlooked it, a feature I'd really like to see added is some shutdown control for the remote production server. At present, 360Deploy appears to give connected users little to no notice that the DB is going offline when it runs. It would be pretty great if 360Deploy had options like these: (A) Scheduled process to migrate dev-->production will only execute if 0 connected users are logged in at that time; availableh options to delay migration by a user-defined length of time waiting for them to log out on their own (e.g. run this schedule at 2:00am but wait up to one hour until there are zero users logged in. Also don't let anyone else log in in the meantime; if after one hour there are still users lingering on the system, go to (B) below). (B) Scheduled or on-demand process to migrate dev-->production would allow a user-defined shutdown timer (e.g. 5 minutes) and a user-defined broadcast ("please log out, system is going down for scheduled maintenance; expected downtime is xyz minutes" etc) to give users a less abrupt experience. (C) Super-ideal would be timers and notices for the DEV server too since we sometimes have more than one developer working on the local dev file. Our system is accessed globally by a dev team and by end-users so there is no handy 'after hours" time of day/night where we can reliably know that there won't be someone connected on either side of the Migration flow. I realize those are icing-on-the-cake features but they sure would be welcome.

I was curious to try out the Deploy2 plugin with my own solution which is considerably larger and more complex than the provided demo solution. Since the demo only works with files named 360Deploy demo solution.fmp12, I renamed my solution according to that naming convention. But now I don't get the option to copy/paste scripts into the solution. Is that an intentional roadblock in Demo mode, or am I missing a step that re-enables that setup step?

I had some installation problems so the process went back and forth enough times that I lost track of all the steps I did or didn't take. Now that I have the demo working I'm realizing I may not have entered any information to validate that I have an FMDS subscription required to access the FM Migration Tool. So that leaves me wondering in general: Does use of 360Deploy2 require one to have such a subscription or is your solution completely independent of that tool?