BuildMaster Feature Listing
BuildMaster delivers a series of robust features unparalleled by other build-promote-deploy-distribute tools.
BuildMaster allows you to create specialized workflows that describe the transition or promotion of your software
through its testing environments and ultimately into production.
Generally your applications will use the same
workflow for every release, but occasionally there may an emergency fix that requires a separate workflow that
defines an immediate deployment to your production environment.
Workflows can be defined such that approvals are required before a promotion is allowed.
Approvals can be targeted to a specific user or a group of users such as testers.
A detailed history of all approvals is maintained by BuildMaster, so there will always be a record of promotion approvals.
Any user of the system with the appropriate privileges can force the promotion of a build regardless of approvals.
A Build Artifact is a "snapshot" of files that were used or created at some point in the
build process. BuildMaster allows you to create any number of artifacts at any
point in the build process, and it stores and manages those artifacts on each
build. The artifacts can be used for building or deploying later on, or simply
kept for archival purposes.
When the "Create Build Artifact" action is executed, BuildMaster will collect all
of the files in a target directory, compress them in a ZIP file, and save it to the artifact library.
Once a build artifact has been created, it can be deployed during any deployment plan.
Each artifact you create as part of the build and deployment process is attached to the build,
and may be downloaded by any user with sufficient privileges.
BuildMaster maintains a comprehensive audit trail of user and system-initiated events covering every
aspect of builds, promotions, executions, deployments, and administration. With BuildMaster, answering
the question of "who did what, and when?" becomes easy.
BuildMaster's integrated event log provides detailed, persistent auditing of all actions taken in the system.
Detailed Event Records
Additional relevant information is stored when an audited event occurs including the associated user, the date and time of the event, the application, and more.
Set up a notifier to receive an email any time a specific auditable event occurs. >
Builds and Deployments
Create plans for easy, reliable, one-click builds and
deployments. Make your build process self-documenting and
Schedule your builds or promotions to occur when you want them, or set up a recurring
build to happen as often as you would like.
Easily examine the output of every step of your plan. Output from scripts is logged along
with all BuildMaster actions, so you won't miss anything. Quickly isolate and solve build
problems and deployment plan bugs.
Have BuildMaster automatically kick off a build when files have been checked in to source
control, or start a new build when another tool or script accesses a special URL.
Create artifacts at any point in your build, and let BuildMaster organize them in its library.
Associate artifacts with individual deployable components of your applications for streamlined
Separate your applications into distinct components called deployables. A deployable is a distinct element in a BuildMaster application and may be something like a web service or a business logic library.
BuildMaster's automated deployment system is designed to be a repeatable method in which to release software.
Sometimes there are cases when one-time manual changes must be made to an environment before software can be
promoted to it. For example, if you've just added a new website or service and wish to have BuildMaster automate
its deployment, you must actually create that website in IIS/Apache or register the service before it can be deployed.
Track Manual Changes
Change Controls are tracked per-application, per-release on the release details page.
See who performed which change control item in any environment.
If your process dictates that all Change Controls must be performed before promotion to a specific environment,
you can add a Promotion Requirement to enforce this rule.
Perform During Deployment
Most of the time, Change Controls can be performed before or after a deployment, but if a pause in automated deployment is
necessary, there is an action to wait for all Change Controls to be performed.
Instanced Config Files
BuildMaster maintains separate instances of your configuration files, so you will always deploy the right settings to the right environment
For each instance, BuildMaster also stores previous versions of configuration files, so you will never lose old values. Keep the benefits of storing configuration files in source control with none of the drawbacks.
Web configuration files may contain sensitive information such as database connection strings or site security configuration
that developers should not have access to. BuildMaster allows you to restrict access to configuration files with its robust security model.
Track all past deployments, so you will always know what files have been deployed, when they were deployed, and who deployed them.
Deploy your configuration files automatically by adding a simple action to your deployment plan. Whenever your application is promoted, the correct configuration file instance tied to the correct release will be deployed.
Manually deploy a configuration file instance anywhere at any time using a simple web interface.
Simplify your configuration files by defining a template. Provide replacement values for each instance and BuildMaster will generate the file for you as it is being deployed.
BuildMaster can integrated with numerous version control systems (see integrations) to perform
Continuous Integration directly, or can integrate with CI systems such as TeamCity, Jenkins, Hudson, etc.
Scheduled and Triggered Builds
BuildMaster accommodates automated builds that can be triggered from source control check-in or scheduled to run at virtually any frequency (i.e. daily, hourly, etc.).
BuildMaster elevates your build process several layers above typical Continuous Integration software. Setting up deployment plans for additional environments such
as QA testing, staging, or production offers a repeatable, reliable, and auditable approach to your application's entire lifecycle – not just from its source code to a development build.
Deployment plans can be set up such that passing unit tests is a requirement for the software to be built to an integration environment. BuildMaster also supports
custom static analysis tools.
Build Results and Auditing
Whether the source code builds successfully is only a single aspect of the application lifecycle. BuildMaster's build results summary will display the status of the build,
the build's current environment (staging, production, etc.), any awaiting or received approvals, build artifacts, build notes, and test results.
BuildMaster works with any database using a provider. For a list of included providers, see toolset integration.
BuildMaster offers built-in actions that perform database backup or restoration which can be automated in your deployment plans.
Define as many database providers for your applications as you need. For example, create one for each of your different environments and let BuildMaster manage connection strings for you.
When BuildMaster is managing your change scripts, you can just let it execute all scripts tied to a release to instantly produce the database schema from that release, no matter which version you are starting from.
Manage Change Scripts
Let BuildMaster keep track of which schema changes have been run against which database, so you will never need to worry about accidentally running the same script twice.
Database providers are extensible in BuildMaster, meaning that even if support for your database is not included, support can be easily added using a BuildMaster extension.
Automated Script Execution
Execute scripts as part of your deployment plan against any provider using a simple action.
Database change scripts do not necessarily have to be automated. Sometimes there is a quick fix that needs to get into production as soon as possible. BuildMaster lets you execute your change scripts the moment they are uploaded.
Change Script History
Every script execution is tracked and stored in a convenient history to see which script was run in which environment at which time. Doing so means BuildMaster will refuse to run the same script twice in the same environment.
Oftentimes only the DBAs will want to control the ability to run scripts. BuildMaster offers a way to permit or deny specific users or groups these privileges.
Download all change scripts to a self-contained executable file that can be used to run scripts against any arbitrary instance of your database. Generate this tool in your build plan and include it in an installer to painlessly upgrade or initialize your users' databases.
BuildMaster solves the problem of dependency management with a concept known as Deployables - a distinct element of a software application such as a web service or business logic library. Learn more about Dependency Management in BuildMaster.
Imported Deployables allow a deployable (such as a framework) from one application to be consumed by another application. This enables the consuming application to use a specific version of the imported deployable. For frameworks, this means that applications can pick the appropriate version – whether that means the latest version, or the version they were using previously.
When a dependency exists, BuildMaster enforces the relationship, and requires that the appropriate deployables are selected for building and releasing.
BuildMaster includes a library of actions and external tool integration, but no software can perfectly accommodate every type of application out of the box. Fortunately, BuildMaster is highly extensible, allowing virtually anything to be automated. Learn more about extensibility in BuildMaster.
Easily configure BuildMaster to run a script or tool on any server with a BuildMaster
Agent. Leverage existing build scripts to make getting started easy.
Have BuildMaster verify that an application is ready for promotion to a specific environment
by using your own custom tool or integrated Promotion Requirement.
Write your own custom action in C# or any other .NET-based language to automate virtually
any build or deployment task.
Write a custom trigger, which allows your code to take action when a specific event
has occurred in BuildMaster.
Write a custom Provider in C# or any other .NET-based language to let BuildMaster work with
any database, source control system, or issue tracker.
Large software applications will usually have teams of some combination of developers, testers, network administrators, and others that
should be kept informed of events such as builds and deployments. BuildMaster provides e-mail notifications to allow users to remain informed.
Receive an email notification when an execution in BuildMaster has completed and know instantly when your promotions have succeeded or failed.
Detailed Execution Log
HTML-based emails can provide a quick way to visually identify problems in executions and builds.
Receive an email notification when an approval is required for a build to be promoted.
Receive an email notification when a new release of an application has been deployed.
BuildMaster's notification system is extensible by design. If execution and release notification emails are not sufficient for your organization, a new notifier may be developed that subscribes to any of BuildMaster's rich set of events.
Similar to the approval process, a Promotion Requirement is a step added to a deployment plan workflow that
will block promotion to a specific environment until the requirement has been deemed "completed". BuildMaster includes a number
of built-in promotion requirements, and they are an extensibility point as well.
Enforce Issue Tracking Status
Ensure that all issues are closed or resolved before a promotion to the next environment.
Guarantee Passing Unit Tests
BuildMaster can prevent promotion of a build to an environment if any unit tests were run and have failed.
Have BuildMaster verify that an application is ready for promotion to a specific environment by using your
own custom tool or integrated Promotion Requirement.
A release represents a planned set of changes to an application. The release could be planned far in advance and require tens of thousands of developer hours to implement, or it could be a single line change rushed to production in an emergency. Explore release management features further.
BuildMaster stores the full history of your releases complete with direct links to any information relevant to a particular release.
A summary of all the information pertaining to an individual release can be found on a single page.
Release numbers are used to uniquely identify a release of an application and determine the sequence of release in an application relative to other releases.
BuildMaster currently offers 3 main types of release numbering: major.minor, major.minor.revision, and numeric/date-based.
Adding notes to your release is a simple way to track any miscellaneous data pertaining to the release.
Reporting & Static Analysis
Since BuildMaster can run virtually any executable during a deployment plan, reports can be generated from your favorite
static analysis tools and the results can be associated with the particular build.
Using other built-in actions, you can browse reports that are generated from a directory of files, from supported tools, or
from a command line tool.
Write your own custom reporting action in C# or any other .NET-based language to automate virtually any
reporting or static analysis tool that produces textual output..
BuildMaster can either use its own built-in authentication provider, or integrate with an existing LDAP directory. Any task that can be performed in
BuildMaster requires a specific privilege which can be granted or denied to custom privilege collections known as roles. Roles can be defined as necessary
depending on your applications.
BuildMaster can either use its own built-in authentication provider, or integrate with an existing LDAP directory.
Privileges and Roles
Any task that can be performed in BuildMaster requires a specific privilege which can be granted or denied to custom privilege collections
known as roles. Roles can be defined as necessary depending on your applications.
Users and Groups
Users and groups can inherit privileges by assuming specified roles.
Privileges can be removed granularly. If developers and testers do not need access to the production environment, access can be denied.
Unit tests are a useful way to test the individual components of your software. BuildMaster integrates with many unit testing frameworks including
NUnit, JUnit, Gallio, and more. See the Integration page for a complete listing.
BuildMaster includes a built-in test action for your deployment plans that will store your test results automatically.
Test result details are recorded and stored with other details of your build.
BuildMaster offers a detailed view into each unit test, providing insight into specific test failures.
Guarantee Passing Unit Tests
BuildMaster can prevent promotion of a build to an environment if any unit tests were run and have failed.