![]() |
![]() |
Parabuild automatically manages generation of product version numbers and provides flow control for release builds.
Continuous Integration builds provided by Parabuild ensure that new changes do not break the project code base. Parabuild starts automatic builds at every check-in or a group of check-ins. Parabuild reports build results through e-mail and instant messaging (IM).
Scheduled builds are a perfect fit for running nightly, daily, or QA builds. With Parabuild scheduled builds are practically unbreakable. Parabuild uses patent-pending technology to make sure that scheduled builds do not break even if the current code base is broken.
Manual Builds run on the build administrator's request. Manual builds can be used for producing patch builds off short-living bug-fix branches.
Parabuild supports running builds on remote build boxes. Build manager and remote builders can run on different platforms. Windows, Cygwin, Linux, Solaris, HP UX and generic Unix, including Mac OS X, are supported. Parabuild maintains the access to build administration, statuses, logs and results from a single build and release management system even if a build run remotely.
This is the coolest feature we have ever added since introducing the remote builds! Now it is possible to launch and run multiple builds on multiple hosts and platform in parallel. Parabuild ensures that all builds run against the same code base and have the same build number or product version:
Parabuild helps create a distributed build infrastructure that before could take you months and sometimes years now in a matter of minutes! Parallel builds are especially suitable for industries developing software that has to run on multiple platforms such as computer game development.
Applications of parallel builds are many. The most obvious include multiplatform building and testing here the build is considered clean and if it was successful on all platforms, and build acceleration that can be easily archived by moving parts of a whole build process to multiple host.
Build configurations can define one or more build steps. Each build step may have its own build script, success and failure patterns, and a timeout.
Parabuild will build any project that can be built from a command line - shell scripts, Perl, qmake, ElectricAccelerator, make, MSBuild, MSDEV, nmake, ANT, nANT, Maven, Jam, VB - you name it.
It is possible to go back in time and to re-run an arbitrary build. This feature can be used to produce QA builds, release candidates or release builds.

Managing product versions with Parabuild is trivial. It provides support for generating product versions using flexible version templates and manually or automatically incremented counters:

Once version counter is defined and enabled, Parabuild will make it available on build start screen. Generated versions are recorded. Build scripts can access the generated version through the shell variable PARABUILD_VERSION. Parabuild ensures that generated product versions do not have duplicates.
Build parameters allow controlling build behavior at run time. Examples include automated deployment of build results to a QA environment or even releasing a product at a single click. Build parameters are passed to the build script as shell variables:

The build parameters are entered when a build administrator requests the build to start. The parameters can be used by the build script to alter the build sequence. The "Start build" screen now allows entering a build note and requesting labeling/tagging if the build is successful. One of the uses of this feature is build promotion:

It is possible to cherry-pick a particular hour and run a daily or a nightly build even if there have not been new changes. This feature is useful when your process requires running a build at given time:

Parabuild allows configuring running multiple builds at a single Parabuild instance, including builds running on remote build boxes.
Parabuild detects build failures by inspecting the error code returned by a build script and/or by finding configured textual or regex failure patterns in build logs. This allows for more fine-grained recognition of the successful and failed builds based on the content of the build logs.
Parabuild allows setting and enforcing a build timeout per a build step.
Parabuild supports a special "finalizer" build step. This step will run in the end of the build sequence without regard to the outcome of the previous build steps. You can use this step to collect and deploy build results to a QA environment even if a previous step running developer unit tests has failed.
A leading build in a parallel build list is guaranteed that its finalizer step is run after dependent builds have finished. This allows for build and test acceleration via distribution of load to remote builders under Parabuild control.
Build sequence configuration now allow to disable a particular build step without deleting it.
Some build configurations require to continue building if a build step failed. For instance, an automated test may fail but your quality assurance group still would like to test the results of the build.

An administrator may make results of a build run downloadable through the top navigation menu. Access to the published build results is controlled by server's security.

Once build results groups are defined, it is possible to publish build results right off the build results page. Also, new build results page allows to delete selected build results:
