A Comparison: BuildMaster vs. Octopus Deploy

KB#1063: Last Updated September 20, 2021

Octopus Deploy and BuildMaster are two different products that can both be used to automate deployments. There are a lot of technical differences, but the overall approach to the problem is the best starting point for comparing the two.

Packages vs Applications

Octopus Deploy uses a package-based approach for release automation. This means that your applications must first be able to be broken-down into small, discrete, and independently-versioned “packages”, and then be built and tested by a continuous integration server like Team City or Jenkins. Octopus will then take that package directly from the CI server (or a package repository like ProGet) and deploy it to the servers you specify.

BuildMaster uses a process-based approach, which provides for a lot more flexibility in where application code comes from, and how it is deployed. You can import build artifacts directly from a CI server, or even build them yourself using a build plan. This means you can perform end-to-end continuous delivery of smaller applications, or manage complex – even mainframe – releases of larger, monolithic applications.

Companies: Octopus Deploy vs Inedo

Octopus Deploy is a single-product company, which means they focus on a very specific need and fulfill a singular aspect of your software delivery and DevOps processes: application deployment. You can use their product for other things, but it’d be like using Microsoft Word to make a spreadsheet.

At Inedo, we publish a suite of DevOps tools to serve a broader segment of your software delivery and DevOps processes. Our products even have some functional overlap, which means you can use the right tool for the right application, and easily migrate between tools if the requirements change later.

Userbase: Release Engineers vs Entire Team

Octopus Deploy is designed to deploy packages from a continuous integration tool. This function is typically performed by release engineers, and not too many other members of the organization will use the tool. This is likely why the product is licensed per server/target, instead of per user.

BuildMaster, however, was designed to be used by all members of the software delivery process – from developers (for integration), to testers (to approve a release package), and even managers (to see statuses and dashboards). This is why we license per user.

Free/Community Edition

As of v4, Octopus Deploy has discontinued their free version, largely because they have a very inexpensive starting tier, and let you scale up licensing as you use it.

BuildMaster has a powerful free version: the only restriction is all users in the free version are administrators (i.e. have unlimited access). This rarely effects small and single-team use, whereas a multi-team enterprise will rarely have a problem budgeting for our paid edition (which also includes enterprise support).

Basic Deployment vs The Inedo Execution Engine (OtterScript)

Octopus Deploy runs one or more “steps” when deploying a package. The primary step is the Deploy Package Step, which copies the package contents to a target directory, and depending on which “features” are selected, performs basic configuration for IIS website, Windows Service, etc. You can run custom PowerShell Scripts before and/or after each step to fill in any gaps, and run steps in parallel.

BuildMaster, on the other hand, uses the Inedo Execution Engine to execute a deployment plan you create using OtterScript, which is a domain-specific language designed specifically for our products.

These deployment plans will contain various statements and “operations” (e.g. IIS::Ensure-Site, or Deploy-Artifact) organized into blocks such as if/else, try/catch, for each, etc. If you’re already familiar with general scripting or programming concepts, the Visual Plan Editor will be trivial to learn.

In addition, the execution engine was designed to seamlessly integrate with PowerShell, and offers not only basic PowerShell execution (similar to Octopus, through the PSCall Operation), but other tight integration points:

Inline PowerShell Execution

You can use PSExec and swim strings to directly incorporate and execute PowerShell:

psexec >>
  # delete all but the latest 3 logs in the log directory
  Get-ChildItem "E:\Site\Logs\$ApplicationName" |
     Sort-Object $.CreatedDate -descending |
     Select-Object -skip 3 |
     Remove-Item
>>;

The execution engine will seamlessly replace variables within your PowerShell script, so in the example above $ApplicationName might be defined as a configuration variable.

Evaluating PowerShell Literals

With PSEval, you can quickly evaluate PowerShell expressions as variable values. For example, say that you wanted to convert the value stored in one variable ($minutes) to milliseconds. You could PSEval the simple expression $minutes * 60 * 1000:

set $milliseconds = $PSEval($minutes * 60 * 1000);

$PSEval actually runs the expression on the server currently in context, so use it inside of an If/Else Block to perform different operations depending on the results of the expression on that server.

Conclusion

Although Octopus Deploy and BuildMaster can both be used to automate deployments, their approach is quite different. When exploring deployment automation tools, you should consider a simultaneous evaluation of both products.

Support