Upgrade 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 new QuickBuild version following the installation guide.
3. Open a command prompt window, switch to sub directory bin under QuickBuild's installation directory, and run command migrate.sh (or migrate.bat on Windows platform) with a param pointing to QuickBuild 1.x's installation directory.
4. After migration, please check the file migrate/migrate-log.html under QuickBuild's installation directory for all settings that can not be migrated and needs to be re-configured.

Important changes that affect 1.x users

1. QuickBuild is no longer able to deploy as a WAR into other application servers. Instead, it always run as a standalone application, either in foreground mode, or in service mode.
2. Configurations can now be added/removed/copied/moved directly at dashboard page if login as administrator.
3. Full name of configuration is now separated by character '/', instead of '.'. For example, to refer to configuration project1 defined under root, the name root/project1 should be used instead of root.project1.
4. Everything defined in the configuration is now inheritable except for name and description.
5. Only QuickBuild administrators (can define more than one admin account) can now edit settings/repositories/steps of configurations for security reasons.
6. Configuration settings such as build necessary condition, variables definitions, promote settings, build clean up strategies are placed into advanced settings tab.
7. 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.
8. 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.
9. 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.
10. 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.
11. 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 workspaces of all configuration under the directory /workspace hierarchically. To do this, just define workspace property of the root configuration as below:

    /workspace/${current.pathName}
    

12. The build cleanly option of configuration is removed since it is not flexible. Instead, each step can be configured to clean up the workspace conditionally (through the property workspace cleanup condition), and this gives user the flexibility of defining custom behavior of clean build. For example, if you have a checkout step checking out code at agent1, and deliver code to agent2 to build with a build step. You may want to define two build type:
    clean build: workspace of agent running the build step needs to be cleaned up before running the step, while workspace of the agent running checkout step should remain untouched.
    increment build: workspaces of both agents should remain untouched.
    For scheduled builds, the increment build type should be used; for manual builds, a dialog should be presented to give user a chance to decide whether or not perform a clean build.
    To accomplish this, define a configuration variable named buildCleanly with the value being false, and set the prompt setting of the variable as checkbox. Then define property workspace cleanup condition of checkout step as false, and define the same property of build step as vars.get("buildCleanly").booleanValue.
    In this way, you've defined your own notion of clean/increment build. You can even define three or more build types by using the selection box prompt setting.
13. By default QuickBuild does not prompt for build version when manually triggering a build. To get build version prompted, define a variable with prompt setting being text input, and reference value of this variable in next build version property of the configuration like below:

    vars.get("buildVersion")
    

    Here buildVersion refers to name of the variable defined above. Further more, value of the variable can be specified as:

    version-prefix-${vars.get("nameOfBuildNumberVariable").increase()}
    

    Then version of the build will be auto-increasing if user has not specified value of the variable or if the build is triggered by a scheduler.

14. By default QuickBuild does not prompt for build version when promoting a build. However, version of resulting build can be controlled using almost the same techinque as specifying build version when manually triggers a build mentioned above, with the exception that the variable should be defined as a promotion variable in promotion setting section of the configuration. Specifically if you want to have the resulting build always has the same version as the promoted build, just set the variable as not prompted and specify value of the promote variable as:

    ${build.version}
    

15. For Accurev users:
    • By default QuickBuild does not sync replica when detecting changes. To enable the sync, please edit Accurev plugin setting by navigating to page Administration/Plugin Management, and set proper value for property replica sync condition. For example, this condition can be defined as true so that all defined Accurev repository should sync replica before detecting changes, or can be defined as vars.get("syncReplica").booleanValue, so that the configuration variable syncReplica can be used to control whether or not sync replica when the configuration is triggered.
    • Reference tree will always be created now for build purpose.
16. For CVS users: Multiple modules with different labels/branches can not be defined to checkout inside a single CVS repository for simplicity reasons. If you want to check out from different modules of different labels or branches, please define multiple CVS repositories and check out from them respectively.
17. For StarTeam users: Modules concept is removed and multiple views can not be defined to checkout inside a single StarTeam repository for simplicity reasons. If you want to check out from different views, please define multiple StarTeam repositories and check out from them respectively.
18. For Subversion users: Modules concept is removed and only one checkout url can be defined in a single Subversion repository for simplicity reasons. If you want to check out from different urls, please define multiple Subversion repositories and check out from them respectively.
19. For Visual SourceSafe users: Modules concept is removed and only one project can be defined in a single Subversion repository for simplicity reasons. If you want to check out from different projects, please define multiple VSS repositories and check out from them respectively.