Easy install process - simply download on your server and configure. 360Deploy ships with a guided configuration, so setup is simple and fast!
At the click of a button, deploy your development environment onto a production server while keeping data intact.
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!
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.
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.
360Deploy 2 leverages the new FileMaker Data Migration Tool, making the import process extremely
while maintaining the ease and automation of 360Deploy. Vertical Market solution developers will
especially benefit from 360Deploy 2, as it allows for simultaneous remote deployment to multiple
servers. Developers with shrink-wrapped software can do a simultaneous version update to
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|
|Simultaneous deployment to multiple servers|
|Sets the next serial number|
|Does not require familiarity with command-line|
|Auto-detects server OS and uses right migration tool|
|Automatically opens and closes files on server|
|Emails you a report when complete|
|Graphical User Interface to faciliate migration process|
|Uploads files to the server for you, renames, and resumes|
|Requires purchase of FDS|
|Data migration is fast|
|Automatic deployment from separate dev server|
|Includes email and phone support|
|Scheduling feature: run the deployment unattended|
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
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.
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.