Documentation > Tutorial > 10. Application backup and deployment
10. Application backup and deployment
In web application development, for the purpose of development and deployment flexibility, it's common to have at least two different locations for the placement of the application. One is for the development and testing activity and the other one is for the real deployment of the final tested application. These two different locations might be provided at system's directory or server level. Migration of application between these two different locations requires backup operations of related application resources that normally involving application related directory paths and tables.
10.1 Directories and database tablesIt's easy to backup and migrating application resources that are flat file based such as CGI script, view templates, customized application modules, etc. Developers just need to make a backup copy of the related directories and then dump them into the new target location where the framework is also installed. In the case of mygb application, these kind of resources are simply the content of the following directory paths:
10.2 Database table backupManually dump and load all related application tables using SQL command can be tedious and error prone thus the framework provides Perl scripts to specifically support this particular task. At the command prompt go to E:\wmbase\webman directory path and type the dir command to list all available scripts provided by the framework.
From the list there are app_dbt_logic_dump.pl, app_dbt_logic_load.pl, app_dbt_domain_dump.pl, and app_dbt_domain_load.pl scripts that available to help backup and then load back tables into other framework's new environment for real application deployment. As shown below, app_dbt_logic_dump.pl script can be executed to backup all the tables used to store main link structure and some logical parts of mygb application.
After the application name is entered (mygb) the script will continue to make a connection to the current database account used and then start dumping all the related tables.
Do notice that for mygb application, until the last tables are dumped, all of them are stored inside the ./app_rsc/mygb/db/dbtl_2012_09_10/ directory path. All tables are also dumped as *.sql, a text file contains the SQL commands to create table structure and restore back all its items using information and data extracted from the original one.
The next step is to dump tables that are used to store the data related to the application problem domain (guestbook entry). This task can be accomplished by app_dbt_domian_dump.pl script as below.
As shown above, there is currently only single table (mygb_entry) used to store data related to the problem domain of the application and it's dumped in the ./app_rsc/mygb/db/dbtd_2012_09_10/ directory path. Following the framework's directory structure organization, both groups of mygb application tables (problem domain and logical structure) are dumped in the ./app_rsc/mygb/db directory path under other sub directories named based on the current date of the backup operation is made. Inside the windows system where this tutorial is based on, the ./app_rsc/mygb/db directory path is actually referring to the full E:\wmbase\app_rsc\mygb\db directory path. Below is the current content of E:\wmbase\app_rsc\mygb\db directory path after both groups of tables are dumped using the provided scripts previously.
10.3 Application resource deploymentAssume that a new framework's environment has been installed and prepared inside other system's directory let say C:\wmbase. Besides this new base directory, application migration will also requires new database account and new web path/alias for C:\wmbase\public_html directory path. Revise the information explained in installation documentation section to get the basic idea how all these new resource elements could be added and configured. After the database tables have been dumped and new deployment enviroment is ready, the procedures to reload application resources into its new environment can be started. It will begin by making a copy of mygb application related directories from E:\wmbase base directory to C:\wmbase base directory. After this procedure is completed the C:\wmbase base directory should have the following list of directory paths:
The script will ask the application name and the backup date of the database that previously made before can proceed to populate the related tables. Using the given date information the script will execute SQL commands extracted from the *.sql text dump files to restore all related tables' structure and their items.
In the above case the *.sql text dump files are available from the C:\wmbase\webman\app_rsc\mygb\db\dbtl_2012_09_10 directory path. They are actually a copied version taken from the development version located at E:\wmbase\webman\app_rsc\mygb\db\dbtl_2012_09_10. Do remember how *.sql text dump files are organized when table backup operation is made such as explained in the previous sub-section (10.2). Also notice that the database account is still at the "localhost" using same user name "webman" but with new database named "db_wmdep".
After all tables related to application logical structure have been loaded, continue with tables for application problem domain by running the app_dbt_domain_load.pl script as below.
At this stage all related application resources should already available inside the new framework's installation environment. The mygb application can now start to be published to the public via this new deployment environment.
|Copyright © 2012 - 2017, Mohd Razak Samingan, Faculty of Computing, Universiti Teknologi Malaysia.|