Difference between revisions of "360Deploy"

From 360Works Product Documentation Wiki
Jump to navigation Jump to search
Line 20: Line 20:
  
 
Setup involves a handful of steps to get 360Deploy ready. Start by opening the 360Deploy.fmp12 file. This will guide you through the setup process:
 
Setup involves a handful of steps to get 360Deploy ready. Start by opening the 360Deploy.fmp12 file. This will guide you through the setup process:
 
[[File:SetupScreenshot.png|thumb|360Deploy Configuration|upright=.9|right]]
 
  
 
# (Optional) Store server log-in credentials for quicker processing
 
# (Optional) Store server log-in credentials for quicker processing

Revision as of 16:33, 15 August 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 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

Setup

Setup involves a handful of steps to get 360Deploy ready. Start by opening the 360Deploy.fmp12 file. This will guide you through the setup process:

  1. (Optional) Store server log-in credentials for quicker processing
  2. Populating IP addresses and account credentials for both servers.
  3. Copying and pasting of a script folder and generate scripts to the production layout


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.,


CodeSnippet.png


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