QuickBuild 2.0 community edition - the free build server


News: QuickBuild 2.0 community edition - the free build server

  1. The most important features introduced in this version are pre-commit test, advanced build grid, versatile build reports, graphical build workflow design, visual build promotion, source code view/diff, and build comparison. It also includes enormous improvments such as intuitive user interface, fine-grained permission control, real time build progress and log monitoring, variable prompting. Feature highlights: 1. QuickBuild organizes projects in a hierarchical structure, and utilizes concept of inheritance and overriding to encourage build definition reuse. 2. With the introduction of proof build feature, developers can run continuous integration against their uncommitted changes on the build server. If successful the build server can commit the changes for developers automatically. This reduces the risk of committing "bad" code to SCM to the minimum. 3. Project metrics can be collected and analyzed during the build process, and useful information will be disclosed in the form of elaborated build reports. For example, QuickBuild can tell which tests are failed most frequently, which tests are taking the longest time, which files are committed most frequently, or which users are committing most frequently, etc. 4. Flexible build workflow definition. In QuickBuild, build workflow is modeled as sequence of build steps. These steps can be visually organized to execute sequentially or parallelly on one or more build agents. For example, you may checkout different part of the product from different agents simultaneously, build and test them separately, and send the build results to another agent for further processing, such as integration tests, product packaging, etc. 5. Build lifecycle management. QuickBuild unifies all levels of builds such as continuous integration, daily build, QA and release build. Build can be promoted from one level to another, triggering desired steps such as sending notification, source code re-labeling, etc. QuickBuild enables a build-centric process to drive the smooth delivery of builds between different groups of the team, for example, from developer to QA, from QA to release manager, etc. More information at http://www.pmease.com .
  2. This doesn't seem to have any more features than Hudson other than the pre-build concept, but I'm not sure how useful that really is.
  3. This doesn't seem to have any more features than Hudson other than the pre-build concept, but I'm not sure how useful that really is.
    As a QuickBuild developer, my opinion might be biased, but QuickBuild differs from Hudson in below areas besides the ability to run proof build (or pre-commit test): 1. It tries to be flexible and is very convenient when comes to manage builds for many configurations. Just taking a simple example: if you want to set up build for multiple branches in Subversion, you may define a project level configuration checking out and build against a parameterized svn url svn://scm-server/project/branches/${vars.get("branch")}, and then create multiple branch level configurations just to override the "branch" variable. 2. The whole build lifecycle management. For example, developer may promotes a roughly tested dev build to be a QA build, and QuickBuild will notify testers about QA build availability. After a QA build passed strict tests, release engineer can proceed to promote it as release build to make it available for public access. Also the proof build feature proves to be very useful since it pratically avoids committing broken code into SCM, and is a must-have feature for so called next generation continuous integration servers.
  4. Quickbuild 2.0[ Go to top ]

    As a regular user of Quickbuild 2.0, I can say that I find it extremely easy to use. My past experience with Hudson was that it was not nearly as easy to configure and use as Quickbuild. From our standpoint, I think one of the biggest differences is the hieararchal configuration, which is something I don't see in hudson (or at least haven't seen in the past, and suprise surprise, dev.java.net is down again at the moment). Also, having a support option is a huge advantage for us, and I can say that Robin gives a very quick turnaround for fixes. Finally, choice is never a bad thing. Just because hudson is out there, doesn't mean there is not room for something else. Personally, i'm no fan of maven, but people said the same thing when maven first showed up. "Why do we need yet another build tool?"
  5. Re: Quickbuild 2.0[ Go to top ]

    Another happy user here. The hierarchical configuration parametering with variables is a clever design, and it enables us managing over 2000 configurations in an incredibly easy and elegant way. Before going with QuickBuild, we tried a number of other build solutions and none of them is comparable at this side. We are also very impressed by the new JUnit reports in 2.0, which discloses much more information than the default html report generated by Ant. They look sexy and our developers just like it. Congrats to QuickBuild team and thanks for a fantastic product!
  6. So how does this compare to teamcity ?
  7. So how does this compare to teamcity ?
    To answer this question, I checked TeamCity documentation and get below impression on the difference between QuickBuild and TeamCity. Please correct me if I am not right: 1. Proof build TeamCity calls this as pre-tested commit (or remote run) and implement it through IDE plugins. This has the benefit of requesting proof build directly from IDE, but has the drawback of leaving this feature useless outside of supported IDE and SCM pairs. QuickBuild implements this feature through user agent and user requests proof build through QuickBuild web page (and will be able to do this through desktop monitor in future versions), which is IDE independent. 2. Build grid It seems that a single TeamCity agent is designed to run only one build, and a build is designed to only run on one agent. To set up a multi-platform builds, multiple configurations need to be created with each running on a specific platform. If you want to aggregate these platform results, you might need to create another configuration and have it dependent on these configurations to retrieve build results. QuickBuild agent is able to run multiple builds, and a single build can contain multiple steps which can run on multiple agents sequentially or parallelly. For multi-platform build, one can create one configuration and add multiple steps with each step running on different platforms. Platform results can be collected through an aggregate step in the same build. 3. Test reports TeamCity seems to be able to discover tests automatically and support more reports than current version of QuickBuild. TeamCity can also arrange tests order so that last failed tests can run first to provide fast feedback. 4. Build setup TeamCity is more easy to set up with its wizard, while QuickBuild is more flexible with its configuration hierarchy, steps, and variables. 5. Build lifecycle management QuickBuild has the concept of build promotion to apply additional workflow to an existing build such as deployment, tagging, publishing. I haven't find the equivalent in TeamCity.