Difference between revisions of "360Deploy"
(→Setup) |
|||
Line 25: | Line 25: | ||
#Install the plug-in in the FileMaker client from which the deployment will be triggered. | #Install the plug-in in the FileMaker client from which the deployment will be triggered. | ||
#Run the 360Deploy file and go through the configuration. This consists of: | #Run the 360Deploy file and go through the configuration. This consists of: | ||
− | + | ** Populating IP addresses and account credentials for both servers. | |
− | + | ** Copying and pasting of a script folder and generate scripts to the production layout | |
− | + | ** (Optional) Store server log-in credentials for an easier process | |
Revision as of 17:06, 21 July 2017
Overview
360Deploy is a product aiming to simplify the tedious process of deploying a development database onto 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 is that which continuously hosts solutions for clients, whether through FileMaker clients or via WebDirect. The development/staging file is the one to which 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. 360 Deploy 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.
- Ideal for frequent upgrades to a databases of any size
- Minimizes file downtime, only pausing file temporarily during import of data
- Drastically reduces complexity and time required to upgrade new database architecture
- Includes import of scripts and calculations
Setup
Setup involves a handful of steps to get 360Deploy ready.
- Run the installation file on the servers which host the production and deployment databases.
- Install the plug-in in the FileMaker client from which the deployment will be triggered.
- Run the 360Deploy file and go through the configuration. This consists of:
- Populating IP addresses and account credentials for both servers.
- Copying and pasting of a script folder and generate scripts to the production layout
- (Optional) Store server log-in credentials for an easier process
Required database changes
- Enable fmapp and fmurlscript for databases in Extended Privileges
- Databases should be password protected (required by default in FileMaker Server)
- Have administrative credentials for both FileMaker servers
- Comment out script steps in triggers that automatically make any write operations in startup scripts (set fields, new records). E.g.,
Recommended steps
- If account/password credentials for the Deploy file and both FileMaker Servers match, process will proceed without prompts and pauses.
Random Notes to help write this wiki
3 Choices to deploy DB changes: 1- Make a log of all changes made to development server, then reflect changes onto production server while it's down. 2- Separation model - creates compromises, involves workarounds, has trade-offs, requires technical know-how 3- Import all data from old data into empty clone of new file, make sure serial numbers are manually adjusted, tedious process