360Deploy

From 360Works Product Documentation Wiki
(Difference between revisions)
Jump to: navigation, search
m (Troubleshooting)
(Miscellaneous tips)
 
(8 intermediate revisions by 4 users not shown)
Line 33: Line 33:
  
 
==Setup==
 
==Setup==
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, or if your development databases are not hosted on a server, this only needs to be run once on the Production server. The install is complete and successful when the 360Deploy page is opened in your default browser. Write down the customized name of your instance (if you chose one during installation) for use later during step 3 in the 360Deploy.fmp12 file.
+
View the documentation here on how to get started:
 +
[https://s3.amazonaws.com/static.360works.com/plugins/360Deploy/360Deploy+Instructions.pdf 360Deploy Instructions]
  
Next, open the 360Deploy.fmp12 file. This file does not need to be hosted on a server, although it can be if you prefer. You can complete the set up process on any machine that has FileMaker Pro installed, but for the best speed, either do this on the production server itself or on a computer on the same local network as the production server. 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:
+
== Archive folder ==
 +
Every time that you run a deployment, 360Deploy will put a copy of the previous production database into a timestamped directory in the FileMaker Server documents directory. This way, if anything goes wrong (due to a problem with the deployment, a programming error in the new version, or any other reason), you can simply place this timestamped archive version back into the live database directory effectively roll back to the both the structure and data that existed prior to running the deployment. You can find the archive folder at:
  
* (Optional) Store server log-in credentials for quicker processing. This will skip over password prompts during the import process.
+
Mac:
* Populating IP addresses and account credentials for both servers.
+
<pre>/Library/360Works/Applications/MigrationBackups</pre>
* 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. '''Note:''' add your custom name (if necessary) to the end of the IP address in a <IP_ADDRESS>/CUSTOM_NAME format
+
Windows:
 
+
<pre>C:/Program Files/360Works/Applications/MigrationBackups</pre>
 
+
'''Required database changes'''
+
* Databases should be password protected (required by default in FileMaker Server)
+
* Have administrative credentials for both FileMaker servers
+
* If there is a startup script or shutdown script then either disable these script steps by commenting them out or turning off the script trigger, or create a separate account for running the deploy operation and do not run these steps if running with this account. For example:
+
 
+
 
+
[[File:Screen_Shot_2017-08-24_at_4.20.00_PM.png]]
+
 
+
*A script that is set to run on last window close contains a script step “Close File [Current File]" will cause 360Deploy to hang during the rollout. These scripts steps need to be commented out or an if conditional should be added in the script to skip over this script step.
+
 
+
== Archive folder ==
+
Every time that you run a deployment, 360Deploy will put a copy of the previous production database into a timestamped directory in the FileMaker Server documents directory. This way, if anything goes wrong (due to a problem with the deployment, a programming error in the new version, or any other reason), you can simply place this timestamped archive version back into the live database directory effectively roll back to the both the structure and data that existed prior to running the deployment.
+
  
 
Keep in mind that this archive directory is never automatically deleted, and can potentially consume a lot of disk space if your solution is large. It's a good idea to manually clean up this directory periodically.
 
Keep in mind that this archive directory is never automatically deleted, and can potentially consume a lot of disk space if your solution is large. It's a good idea to manually clean up this directory periodically.
Line 62: Line 49:
 
Also keep in mind that if you are using containers with external storage, that container data is shared between the old and new database versions - there is no separate copy placed into the archive folder. This speeds up the import and conserves disk space, but it also means that if you do need to roll back the database version, changes that were made to the external container data are not rolled back. Use FileMaker Server's built-in backup feature to guarantee a complete backup including a separate copy of all container data.
 
Also keep in mind that if you are using containers with external storage, that container data is shared between the old and new database versions - there is no separate copy placed into the archive folder. This speeds up the import and conserves disk space, but it also means that if you do need to roll back the database version, changes that were made to the external container data are not rolled back. Use FileMaker Server's built-in backup feature to guarantee a complete backup including a separate copy of all container data.
  
== Advanced Options ==
+
== Scheduling after-hour imports ==
+
The script "Upload Files and Start Migration ( $~configuration_id )" is Server Side compatible, and can be used in a Server Side Schedule, which is our recommended way of doing a scheduled deployment. To use this script, we recommend creating a wrapper script, where you can pass in the id of the configuration to the "Upload Files and Start Migration" script.
*You can optionally edit the "360Deploy post-import 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.
+
  
== Performance ==
+
See the example script in the 360Deploy.fmp12 file called "PSOS : 360Store Deployment"
For fastest import speed, run the 360Deploy import process from a copy of FileMaker Pro/Advanced either on the production server, or on a computer on the same local network as the production server. It will not cause a significant slowdown to access your development server over a wide area network.
+
  
Using external container storage provides a modest increase in speed for the import. In addition, it will reduce disk space, because the external container data is shared between the old production database and the new version, instead of being duplicated.
+
To get the id of your configuration, open the data viewer and evaluate the "Configuration::__id" field while you are on the main layout. This will be the value you pass in.
 
+
== Scheduling after-hour imports ==
+
When you click the deploy button, you'll have a choice to schedule the import for any date and time that you choose. Keep in mind that for this to work, the 360Deploy.fmp12 must remain open and running in FileMaker Pro until the scheduled time. In addition, since you will not be present to click on any dialogs, it's a good idea to re-run the final step of pasting the import script into your solution (step 8).
+
  
 
== Miscellaneous tips ==
 
== Miscellaneous tips ==
 
=== Deleting / adding / renaming fields ===
 
=== Deleting / adding / renaming fields ===
Renaming or adding fields in the development database will work fine during the import. Deleting fields will fail, because the import is done by matching order, and so deleting a field on either development or production will cause the remaining fields to 'shift', so the wrong data will be imported into the wrong fields. To solve this problem, either don't delete fields (you can rename them to indicate that they are unused), or delete them from both the production and the development versions - that way the order will still match.
+
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.
  
== Advanced settings ==
+
=== Renaming tables ===
If you would like a post-import script to run that can set default values for fields, do data parsing from previous versions, etc., this can be accomplished by customizing the '360Deploy post-import actions' script. Your script can receive a parameter with the version number of the production database that is being upgraded. Click the 'Advanced options' and follow the instructions there.
+
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.
  
==Troubleshooting==
+
=== Viewing Errors ===
===Import hangs with no dialog on screen===
+
If there is an error with a deployment, there will be a record created in the @AppLog table. You will need to open this layout manually and scroll to the last record.  Look in the "errorDescription" field for more information about the most recent error.
This probably indicates that a startup or shutdown script is halting the process. Add a section like the screenshot shown above at the top of the startup script to exit the startup and shutdown script for automated deployments.
+
  
===Issues with Deploy converting comma (',') character to decimals ('.')===
 
This is likely due to differences in region/language settings on the servers. Make sure the whatever options selected in the deployment environment closely match the options on the production server. On Mac, these can viewed by going to Language & Region, selecting a region, and then going to Advanced to see what the grouping and decimal delimiters are. On Windows, go to Region, Formats, then Additional Settings to ensure the decimal and digit grouping characters are the same as the other server. Note that many regions use a space to serve as a grouping delimiter which is hard to notice unless you click into the text field.
 
  
==="Cannot Open Database, Closed by Server" dialogue during deployment===
+
<center>[[File:ReturntoMainPage.png| 140 px |link=http://www.360works.com/products/ |alt= 360Works Plugins for FileMaker |FileMaker Help]]</center>
This is usually caused by deploying a multi file solution that is both updating files currently on the server as well as deploying new files to the server. If the database that you have declared to be the 'Primary Database' does not yet exist on the server then this error will be thrown. One workaround for this would be to upload a clone of the database that is intended to be the primary database manually before proceeding with the deployment.
+

Latest revision as of 01:48, 4 December 2018

Contents

[edit] Requirements

[edit] Overview

360Deploy is a product that simplifies the tedious process of deploying changes in a development database to an existing production database. This can be done with the click of a button while eliminating human error and reducing the downtime traditionally associated with the process. All that is required is 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.

[edit] 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

[edit] System requirements

  • 360Deploy requires FileMaker Pro or Advanced 16 to run the actual import process.
  • Production databases must be hosted on FileMaker Server 14 or later
  • For technical reasons, FileMaker Cloud is NOT compatible with 360Deploy

[edit] Licensing

There are four types of licenses for 360Deploy. Pricing for each license type is available at http://360works.com/360Deploy by clicking the 'pricing' button.

  • A free demo license, which can deploy to any number of servers. It has one important limitation, which is that it can only be used to deploy databases named '360Deploy Demo Solution'
  • Express Edition: This allows deployment of a single FileMaker solution (this can be a multi-file solution) to a single deployment server
  • Enterprise License: This allows deployment of unlimited FileMaker solutions to a single deployment server. It is not legal to use this license for multiple different clients, for instance in a shared hosting server or vertical market hosted server.
  • Solution Bundle License: This allows deployment of a single FileMaker solution (this can be a multi-file solution) to unlimited deployment servers. The deployed solution can have different names for different customers.

An Enterprise License is included with the 360Works Portfolio License (http://360works.com/portfolio) at no additional charge. Any current Portfolio License holders will be able to immediately start using 360Deploy.

[edit] Setup

View the documentation here on how to get started: 360Deploy Instructions

[edit] Archive folder

Every time that you run a deployment, 360Deploy will put a copy of the previous production database into a timestamped directory in the FileMaker Server documents directory. This way, if anything goes wrong (due to a problem with the deployment, a programming error in the new version, or any other reason), you can simply place this timestamped archive version back into the live database directory effectively roll back to the both the structure and data that existed prior to running the deployment. You can find the archive folder at:

Mac:

/Library/360Works/Applications/MigrationBackups

Windows:

C:/Program Files/360Works/Applications/MigrationBackups

Keep in mind that this archive directory is never automatically deleted, and can potentially consume a lot of disk space if your solution is large. It's a good idea to manually clean up this directory periodically.

Also keep in mind that if you are using containers with external storage, that container data is shared between the old and new database versions - there is no separate copy placed into the archive folder. This speeds up the import and conserves disk space, but it also means that if you do need to roll back the database version, changes that were made to the external container data are not rolled back. Use FileMaker Server's built-in backup feature to guarantee a complete backup including a separate copy of all container data.

[edit] Scheduling after-hour imports

The script "Upload Files and Start Migration ( $~configuration_id )" is Server Side compatible, and can be used in a Server Side Schedule, which is our recommended way of doing a scheduled deployment. To use this script, we recommend creating a wrapper script, where you can pass in the id of the configuration to the "Upload Files and Start Migration" script.

See the example script in the 360Deploy.fmp12 file called "PSOS : 360Store Deployment"

To get the id of your configuration, open the data viewer and evaluate the "Configuration::__id" field while you are on the main layout. This will be the value you pass in.

[edit] Miscellaneous tips

[edit] Deleting / adding / renaming fields

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.

[edit] Renaming tables

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.

[edit] Viewing Errors

If there is an error with a deployment, there will be a record created in the @AppLog table. You will need to open this layout manually and scroll to the last record. Look in the "errorDescription" field for more information about the most recent error.


 360Works Plugins for FileMaker
Personal tools
Namespaces

Variants
Actions
Plug-in Products
Other Products
Navigation
Toolbox