Lightweight, Component-based, and Database-oriented Web Application Framework

About | Overview | Documentation


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 tables

It'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:
  • E:\wmbase\public_html\cgi-bin\webman\mygb
  • E:\wmbase\public_html\webman\mygb
  • E:\wmbase\webman\app_rsc\mygb
  • E:\wmbase\webman\pm\apps\mygb
Detailed explanations about the content of each directory paths above have been given at the end of the previous earliest main section of this tutorial (1. Create new application).

Other application resources need to be backup before the migration procedure can be started are the database tables. Inside the framework implementations, database tables are categorized into two different groups. One is for application problem domain and the other one is for application main link structure and logic. For mygb application there is currently only single table used to solve the domain problem that is the mygb_entry table. Main link structure and some parts of the logic of mygb application are supported by the long list of tables as follows:

  1. webman_mygb_blob_content
  2. webman_mygb_blob_content_temp
  3. webman_mygb_blob_info
  4. webman_mygb_blob_parent_info
  5. webman_mygb_calendar
  6. webman_mygb_cgi_var_cache
  7. webman_mygb_comp_auth
  8. webman_mygb_db_item_auth
  9. webman_mygb_dictionary_dyna_mod
  10. webman_mygb_dictionary_language
  11. webman_mygb_dictionary_link
  12. webman_mygb_dyna_mod
  13. webman_mygb_dyna_mod_param
  14. webman_mygb_dyna_mod_param_global
  15. webman_mygb_dyna_mod_selector
  16. webman_mygb_group
  17. webman_mygb_hit_info
  18. webman_mygb_hit_info_content
  19. webman_mygb_hit_info_query_string
  20. webman_mygb_link_auth
  21. webman_mygb_link_reference
  22. webman_mygb_link_structure
  23. webman_mygb_session
  24. webman_mygb_session_info_daily
  25. webman_mygb_static_content_dyna_mod_ref
  26. webman_mygb_user
  27. webman_mygb_user_group


10.2 Database table backup

Manually 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 deployment

Assume 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:

  • C:\wmbase\public_html\cgi-bin\webman\mygb
  • C:\wmbase\public_html\webman\mygb
  • C:\wmbase\webman\app_rsc\mygb
  • C:\wmbase\webman\pm\apps\mygb

The next step is to load the database tables for application logical structure by simply running the app_dbt_logic_load.pl script from inside C:\wmbase\webman directory path as below.


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.