360Deploy




At the click of a button, deploy your development environment onto a production server while keeping data intact.

Current VersionWhat's New?

Own a license?
Download current version.

Learn more about our
Portfolio License bundle!

Features

Simple Configuration

Easy install process - simply download on your server and configure. 360Deploy ships with a guided configuration, so setup is simple and fast!

Minimize Server Downtimes

360Deploy allows you to work on your own development copy, while users still work on the live server. When you are ready, simply configure and click deploy to have your changes migrated to the live file!

Simultaneous Deployment to Multiple Servers

Vertical Market solution? Developers with shrink-wrapped software can do a simultaneous version update to multiple client servers around the world… all with a single click.

Included in the Portfolio Bundle

Receive an Enterprise license, which allows updated file versions for an unlimited number of solutions to be deployed to one production server, along with all products from 360Works when you purchase the Portfolio Bundle.

Need help setting up one of our products?

We are experts in FileMaker, Java, and Amazon Web Services. If you need a customized plug-in, modifications to an existing plug-in, or full plug-in/web app integration services, we can perform these services for you. Please fill out our Quick Form and we will contact you to discuss your solution needs and create an estimate.

Video

About

360Deploy leverages the new FileMaker Data Migration Tool, making the import process extremely fast while maintaining the ease and automation of 360Deploy. Vertical Market solution developers will especially benefit from 360Deploy, as it allows for simultaneous remote deployment to multiple servers. Developers with shrink-wrapped software can do a simultaneous version update to multiple client servers around the world… all with a single click.

Once you press the ‘deploy’ button in 360Deploy, there is nothing left to do. It sends the new version to FileMaker Server (or multiple servers), and then runs in the background on each server, so you are free to continue working, take a break, or head home for the night, knowing that the new version will be safely deployed to users on each server by the time you get back. You’ll receive an email when the process is complete. Skip the hassle of fumbling with files on the server and stick to the “one-button click” of 360Deploy for dev changes!

360Deploy solves the age-old problem of making development changes on one FileMaker database and the need to merge updates with a live production database hosted on FileMaker Server. Current methods of working on a live file, writing script imports, or separating files to work can be undesirable, arduous, risk file corruption, or break an existing process.

FileMaker Data Migration Tool vs. 360Deploy

FileMaker Data Migration Tool 360Deploy
Clones file automatically check
Simultaneous deployment to multiple servers check
Sets the next serial number check check
Does not require familiarity with command-line check
Auto-detects server OS and uses right migration tool check
Automatically opens and closes files on server check
Emails you a report when complete check
Graphical User Interface to faciliate migration process check
Uploads files to the server for you, renames, and resumes check
Data migration is fast check check
Automatic deployment from separate dev server check
Includes email and phone support check
Scheduling feature: run the deployment unattended check

System Requirements

360Deploy requires FileMaker Pro or Advanced 16 to run the actual import process.

Production databases must be hosted on FileMaker Server 16 or later.

For technical reasons, FileMaker Cloud is NOT compatible with 360Deploy.

All of our plugins are designed to run on Mac and on Windows. All system requirements are the same as those of FileMaker. As long as you meet FileMaker's minimum requirements, you can run our plugins in your Mac or Windows environments.

What does the FileMaker community think?

The general opinion of 360Works as a company that always goes above and beyond is well earned.

- Glen Cardenas

We've had great success implementing some of your 360Works products from our developers portfolio already, it's added some great functions to FileMaker for us!

- Mike Beargie

We use 360Works plug-ins with our clients without hesitation. They’re easy to implement, and work dependably, and KEEP working dependably. Their excellent support is just the icing on the cake.

- Scott Love, Soliant Consulting

Q&A

360Deploy automates the deployment of databases from a Development to Production environment. It will handle getting copies of your Dev files, uploading them to the Prod server, importing all the data from the Prod file into the Dev file, then hosting the newly populated Dev file in the place where the Prod file was. With the click of a button, this allows you to merge the schema changes (new layouts, scripts, and tables) from your Dev file, and the data from your Prod file. So you can get the new features you have been developing, along with the data your users have been entering all merged together.

Altering live databases is risky. It is possible to lock tables, causing a pile up on the server, and potentially causing corruption. It is far safer to do your development in a separate, Development copy of your database. However, if you do development in a separate copy, your users will be entering data into the live, Production copy of the database. Now you have a problem, your new features are in one file, but all the data is in a different file. This is where 360Deploy comes in. It is purpose built to merge the development changes from a Dev file with the data from a Prod file, and handle the uploading, merging, and hosting of the newly populated Dev file. Automating this process with 360Deploy also greatly reduces the chance for error during this process, as it is very tedious to do manually.

Review the licensing types outlined here. You can see pricing for licenses at our store page here.

In short, the solution is to use Dynamic Data Sources to control which version of the file (Dev or Prod) uses which External Data Sources (Dev External Data Sources or Prod External Data Sources). There is a longer writeup in our docs with examples on how to do this here.

The script that executes the entire deployment is called: "Upload Files and Start Migration ( $~configuration_id )". This script is server side compatible, and you can specify this script in a server side schedule in the FileMaker Server Admin Console. We recommend this approach for scheduling deployments because of the reliability you get with server side schedules. Read more about this approach here.

Yes, archived Prod files are stored on the Prod server. You can find them in timestamped folders at the locations listed here.

This is a funny question because you would think that the Accounts come from the Dev file like the rest of the schema (layouts, scripts, tables, etc). However, Accounts actually come from the Prod file during a deployment, and are imported into the Dev file. This is really the preferred way to handle this, users have been logging into the Prod file previously, and we still want their accounts to work. So if you have a new user, you can add their account to the Prod file. Then the next time you run a deployment, that account will get merged into the Dev file before it is hosted. All users who could log into the Prod file before a deployment, will still be able to log into the Prod file after the deployment.

Renaming or adding fields in the development database will work fine during the import. If you add fields in your development copy, be aware that this field will be empty after you migrate these changes to the production server, as there will be no data on the production server to populate it. Deleting fields will work as expected, the field will be removed from the production copy.

360Deploy uses the FMDataMigration tool, which will match up tables by id and name first, if no match then by name alone, then by id alone. Renaming tables will work fine as long as a new table is not created using the renamed tables previous name.