Upgrade from QuickBuild 1.x

Migration procedure

1. Login to QuickBuild 1.x as administrator, switch to page Administration/Backup Database, and backup the database as backup.xml under QuickBuild 1.x's installation directory.
2. Install QuickBuild2 following the installation guide. Assume installation directory for QuickBuild2 server is /opt/quickbuild2.
3. Open a command prompt window, switch to directory /opt/quickbuild2/bin, and run command migrate.sh <QuickBuild 1.x installation directory> (or migrate.bat on Windows). The param <QuickBuild 1.x installation directory> should be replaced by the actual installation directory of
   QuickBuild 1.x.
4. After migration, please check the file /opt/quickbuild2/migrate/migrate-log.html for all settings that can not be migrated and needs to be re-configured.

Important changes that affect 1.x users

1. Everything defined in the configuration is now inheritable except for name and description.
2. Configuration settings such as build necessary condition, variables definitions, promote settings, build clean up strategies are placed into advanced settings tab.
3. Expressions have been changed a lot. Due to complexity of expressions, we can only migrate default expressions that have not been changed by users. For customized expressions, please rewrite them based on the scripting help, which can be accessed by poining mouse to the help icon when edit related properties.
4. By default only one promote destination can be defined now. However multiple promote destinations can be enabled by using variables and scripts as explained in help of property configuration when defined the promotion setting.
5. Promotion mechanism is simplified and a QuickBuild repository is no longer necessary in order to fetch files from promotion source. Instead, promotion files are specified when define the promotion settings of related configurations.
6. The step type Send Notification is now removed. To specify receivers and conditions of build notifications, please edit advanced settings of related configurations, and enable proper notifications.
7. By default, configuration workspaces (previously named configuration checkout directory) are created under the workspace sub directory under the configuration directory. However workspace directories of different configurations can be organized to match the configuration hierarchy with the help of scripting. To demonstrate this, assume we have below configuration hierarchy:

   root
       projectA
           componentA1
           componentA2
       projectB
           componentB1
           componentB2
   

   Now we need to place workspace of root ocnfiguration under the directory /workspaces/root, and workspaces of other configuations should be created under directory workspace/root matching the configuration hierarchy, that is, workspace of configuration root/projectA should be workspaces/root/projectA, and workspace of configuration root/projectA/componentA1 should be workspaces/root/projectA/componentA1, and so on. To do this, just define workspace property of the root configuration as below:

   ${current.parent!=null?(current.parent.workspaceDir.absolutePath+"/"+name):"/workspace/root"}