From 360Works Product Documentation Wiki
Revision as of 13:51, 30 August 2017 by Jesse (Talk | contribs)

Jump to: navigation, search




360Deploy is a product aiming to simplify the tedious process of deploying changes in a development database to an existing production database. Developers working on a file can deploy changes made to their database structure at the click of a button while avoiding the downtime and labor traditionally associated with the process. All that is required is the use of our plug-in, some simple configuration, and click Deploy!

For a better understanding, consider the typical FileMaker file development scenario of a production and development server. The production server continuously hosts solutions for clients. The development/staging file is the database where alterations are being made by developers to enhance utility and better serve client's needs. Overhauling the old file to reflect the new one typically involves a process during which production is shut down and administrators sift through tables, scripts, and fields to reflect updates. We seek to bypass this arduous task by automating the entire series of events.

The entire process takes only as long as it takes to import data based on your database size, during which the databases are paused. This allows files to be updated without worrying about how often or when the changes occur. The set up consists of installing our plug-in in the FileMaker client running the deploy file, and some simple script copy/pasting.

Why use 360Deploy?

Altering live databases has traditionally been a tedious, intrusive task. It consists of server downtime and technical labor at the expense of company resources. 360Deploy is capable of doing that in minutes by seamlessly automating the process. What our software does is create a clone of the development database, transfers it to the production server, and then imports data from production into the clone to absorb the new architecture. As a safeguard, a back-up of the production file is also created on the machine before the imports occur should clients wish to revert back to the old structure.

  1. Ideal for frequent upgrades to a databases of any size
  2. Minimizes file downtime, only pausing file temporarily during import of data
  3. Drastically reduces complexity and time required to upgrade new database architecture
  4. Includes import of scripts and calculations
  5. Backs up production file in event changes want to be reverted


First, install 360Deploy on both the Production and Development servers by running the installer for the operating system that you are using. If you are using the same server for both production and development files, this only needs to be run once. The install is complete and successful when the 360Deploy page is opened in your default browser.

Next, open the 360Deploy.fmp12 file. You can complete the set up process on any machine that has FileMaker Pro installed. Running the deploy process from the development machine has shown quicker deploys in testing. The default login credentials are "360Deploy" for the username and password. On first login, you will be prompted to change the password for this account. The file will guide you through the set up process:

  • (Optional) Store server log-in credentials for quicker processing. This will skip over password prompts during the import process.
  • Populating IP addresses and account credentials for both servers.
  • Choosing which files you want to deploy to the production server
  • Copying and pasting of a script folder and generate scripts to the production layout

Make sure to click the "Verify" button after steps 3 and 4 to make sure that you have the Production and Development sides configured correctly.

Required database changes

  • Databases should be password protected (required by default in FileMaker Server)
  • Have administrative credentials for both FileMaker servers
  • If the startup script does any write operations (i.e. Set Field or New Record), then either disable these script steps by commenting them out, or create a separate account for running the deploy operation and do not run these steps if running with this account. For example:

Screen Shot 2017-08-24 at 4.20.00 PM.png

Advanced Options

  • You can optionally edit the "360Deploy post-impor actions" script in your development file to run actions that you might want to happen after the import such as creating new account privileges from a table of users.
  • 360Deploy also has the option to include a version field for your solution. The value of this field will be passed to your post-import script as a script parameter to conditionally run any post-import operations
  • 360Deploy also has the option to pause the databases so your users can not continue to add/modify data while the deployment is running. They will however have read access to the files. Using this option may cause the deployment to seem to hang while importing records. It is important to note that when using this option if the process seems to hang on importing records, open the FileMaker Server Admin console and resume the database so the import can continue.


Import hangs with no dialog on screen

This probably indicates that a startup script is halting the process. Add a section like the screenshot shown above at the top of the startup script to exit the startup script for automated deployments.

Import hangs with import dialog showing

If this occurs, try resuming the production database using FileMaker Server Admin Console. The production databases are normally paused during the import to prevent users from making changes (which will be lost if the import has already run for that table), but sometimes this can cause the import to hang. In our experience, this is usually a one-time problem: Resuming the database once seems to fix the problem permanently, even for future imports that are not manually resumed.

Personal tools

Plug-in Products
Other Products