3.0.0-beta1

Added by Steve Luo, edited by Robin Shen on Jun 24, 2010
You are viewing an old version (v. 9) of this page.
The latest version is v. 40, last edited on Aug 28, 2010 (view differences | )
<< View previous version | view page history | view next version >>

Quick links

Major improvements over 2.x

  1. [Integrate JIRA in QuickBuild] and [integrate QuickBuild in JIRA]
    • Transform JIRA issue keys in SCM commit messages to issue links.
    • Update JIRA issues based on commands found in SCM commit messages. For example, fix TST-123 --time 2d --comment some comment tells QuickBuild to resolve issue TST-123 with a worklog of two days and a comment some comment. Issues will be updatede under the JIRA account associated with the SCM committer.
    • Create JIRA issues under certain conditions and assign to certain person. For example, you may configure QuickBuild to create an issue for build failure and have it assigned to build engineer, or create issues for unit test failures and have them assigned to corresponding developers.
    • Corresponding project versions in JIRA can be automatically released if certain build is successful. Further, build version can be pushed into JIRA as released project version if it does not exist already.
    • Issues fixed in a build can be associated with corresponding JIRA versions automatically via fix version/s field of the issue.
    • Next build version in QuickBuild can be configured to use next unreleased version of corresponding JIRA project.
    • A JIRA issues tab to display information of issues relating to current build, or comparison of two arbitrary builds. Issues can be searched by summary within QuickBuild.
    • A QuickBuild plugin running at JIRA side to disclose SCM changes and builds information for an issue. User may view/diff changed files of issues directly from JIRA without FishEye being installed.
  2. [Integrate with Trac]
    • Transform Trac ticket numbers in SCM commit messages to ticket links.
    • Update Trac tickets based on commands found in SCM commit messages. For example, fix #123 --comment some comment tells QuickBuild to fix ticket #123 with a comment some comment. Tickets will be updatede under the Trac account associated with the SCM committer.
    • Create Trac tickets under certain conditions and assign to certain person. For example, you may configure QuickBuild to create a ticket for build failure and have it assigned to build engineer, or create tickets for unit test failures and have them assigned to corresponding developers.
    • Milestones in Trac can be automatically released if certain build is successful. Further, build version can be pushed into Trac as released milestone if it does not exist already.
    • Tickets fixed in a build can be associated with corresponding Trac milestones automatically via milestone field of the ticket.
    • Next build version in QuickBuild can be configured to use next unreleased Trac milestone.
    • A Trac tickets tab to display information of tickets relating to current build, or comparison of two arbitrary builds. Tickets can be searched by summary within QuickBuild.
  3. [Integrate with Bugzilla]
    • Transform Bugzill bug numbers in SCM commit messages to bug links.
    • A Bugzilla bugs tab to display information of bugs relating to current build, or comparison of two arbitrary builds. Bugs can be searched by summary within QuickBuild.
  4. A general commit message transformer to transform arbitrary snippet of SCM commit message freely. This feature is typically used to transform issue keys into issue links for issue trackers currently not supported by QuickBuild.
  5. Step reuse and repetition
  6. MSTest
  7. Changes search
  8. Build variables tab

Major improvements over 1.x

  1. Native support for a number of build reports. Refer to below documents for details of build reports:
  2. Build statistics. Refer to below documents for details of build statistics:
  3. Build grid support. Refer to below documents for details of build grid:
  4. Introduce the concept of proof build to build/test user's uncommited changes at server, and optionally checkin that those changes automatically if build/test succeeds.
  5. Visually arrange steps to design build process. Refer to below documents for details:
    • [configuration setup]
  6. Build promotion visualization. Source build and destination build will be linked to show the promotion relation.
  7. Fine grained access control when assign permissions for groups.
  8. Be able to customize build option screen and promote option screen when manually triggers a build or promote a build. This is supported through prompt settings of variables.
  9. Builds can run concurrently even for a single configuration to better utilize build grid resource. To configure concurrent running builds for a single configuration, the master step needs to be configured to run on agent instead of server.
  10. Be able to recommend build. Recommended build will have a star icon attached. Promote operation can be configured to only applicable for recommended builds.
  11. Build changes will be collected during a build promotion process. For example, if a release build is generated as result of promoting from a QA build, the change set between current release and last release will be collected automatically.
  12. Be able to view/diff changed source files in the change set panel.
  13. Be able to compare two builds (not necessary ajacent) and generate changes between them.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.