A Comparison: BuildMaster vs Hedgehog

KB#1158: Last Updated Feb 13, 2019

Note: Hedgehog is an experimental product, with it's official release coming in ~2020

Both BuildMaster and Hedgehog can be used to automate the release and deployment of your applications and components, and both have lots of common features and can be used in conjunction with each other. This article will provide guidance on how to decide which tool to use.

Work in progress. This article is a work-in-progress, but we've fielded quite a few questions asking about the difference between these two products, we wanted to publish a preliminary comparison.

Which Tool Should I Evaluate?

In almost all cases, BuildMaster.

While Hedgehog's software itself is production-ready, it's a v1 product meant for early adopters. Like all v1 products, Hedgehog's future is uncertain. While we designed it to eventually take BuildMaster's place, that day may never come.

Another possibility is that we merge Hedgehog back into BuildMaster. This would require us to add successful features to BuildMaster, and come up with a migration path. This wouldn't be too bad, particularly with Rafts and Application Import/Export.

Common Origin: BuildMaster 5.8

BuildMaster and Hedgehog share a common ancestor: BuildMaster 5.8, which was the last of the v5 line.

To create Hedgehog, we started by forking the BuildMaster 5.8 codebase and then removing a tremendous amount of code that was required to support BuildMaster legacy features, including a legacy execution engine, legacy agent model, and all sorts of backwards-compatibility shims. We also disabled or deactivated many features in BuildMaster, such as calendars and Issues and Project Tracking.

After that, we were able to do some major refactoring:

  • Tweak the model to be more flexible and focused on packages
  • Improve the pipeline features
  • Incorporate raft-based storage for content

This split allowed us to build a new, innovative product with all the stability and experience of a successful, well-established product.

Product Changes

Because Hedgehog has fewer features and no legacy code to maintain, we will be able to add features and improvements to the product much more easily. Some of these features may be "reboots" of existing BuildMaster features (like release calendars), or they may be entirely new features altogether.

BuildMaster is still an actively developed product, but the legacy code limits our ability to make certain risky improvements. In addition, we don't want to build a duplicative feature, or drastically change the behavior of an existing feature.

However, because both tools use the Inedo Execution Engine, Inedo Agents, and the Inedo SDK, they will both get the same operational improvements, as well as extensions and plug-ins developed by Inedo and the community.

Applications vs Packages

Both tools can be used for deployment automation, but the way in which they model the problem is slightly different:

  • BuildMaster models applications and releases, which makes it suitable for larger, monolithic applications that tend to have more complex deployment models and release processes
  • Hedgehog models packages, which makes it more suitable for lots of smaller, service-based applications that tend to have simpler deployments and uniform release processes

For example, considering Inedo's application and component portfolio, we use the products as follows:

  • BuildMaster is used to manage the release process and deployment of our products (ProGet, Hedgehog, Otter, and even BuildMaster itself); not only do our products have a complex workflow, but they don't lend to being deployed as small, simple packages
  • Hedgehog is used to manage our dozens of Inedo extensions, which are universal packages and are released on demand

Build or Import Artifacts vs External Packages

BuildMaster was originally designed to retrieve your source code, tag it, compile it, and then deploy the compiled build artifacts through a series of environments.

While many of our users still prefer this simple workflow, dedicated continuous integration servers (Jenkins, TeamCity, etc) have become the most popular way to build code, and as a result, we added the ability to import artifacts directly from a CI server, and then deploy those artifacts.

Hedgehog, on the other hand, is designed to deploy packages hosted in an externally-hosted package server like ProGet. This allows a cleaner separation between build and release tools, and a uniform deployment process for many different technologies.

Of course, because both products use the same extensions via the Inedo SDK, you can perform any of these three workflows in either of the products.

Features vs Simplicity

BuildMaster has more features to support release coordination (such as calendars, issue tracking, and deployables) as well as more deployment features (database change scripts, configuration file assets). While they can be quite useful, these features are unique in the industry, and many don't expect a tool like BuildMaster to have them.

Hedgehog lacks these features, which forces users to simplify their process instead. For example, instead of relying on a database change script management feature, you may have a DBA team manage database changes instead.

BuildMaster vs Hedgehog Terminology

Because of the common origin, and because they are both Inedo products, BuildMaster and Hedgehog share a lot of concepts and terminology.

BuildMaster Hedgehog Additional Notes
Application Project
Deployable - These are replaced with variables and, to some extent, packages
Application Group - Projects can have a parent project, which makes application groups unnecessary
Artifact Attachment
Release Package
Deployment Set
- Package These could be handled, to some degree, with variables in BuildMaster

* denotes v4/v3 terminology