A Comparison Between BuildMaster vs. TeamCity
TeamCity and BuildMaster are different products that solve different problems, and both are commonly used as part of a modern DevOps Toolchain.A side-by-side comparison would be a bit like Word and Excel: Both can be used to create forms that you’ll print out, but if that’s the only thing your business uses Microsoft Office for, you’re certainly not doing it right.
Already familiar with Jenkins? The terminology comparison may help you get a quicker understanding of BuildMaster.
Continuous Integration
vs. Application Release Automation
This can really be boiled down to builds vs. releases.
Fundamentally, builds and releases vary in two distinct ways: Builds meet developer or development needs, and Releases fulfill the IT organization requirements, and deliver end results. By separating tools into these unique and separately functioning categories, you are able to address and solve the individual problem or requirement associated with each.
Although CI and CD are two distinct, separate processes to address two distinct problems, some seek a single, multi-purpose tool to do it all. Obviously, no such tool exists. Just as a Swiss army knife is no replacement for a toolbox, TeamCity is simply not suitable for implementing a modern DevOps process.
Build Jobs as the Center of DevOps?
Like all Continuous Integration tools, TeamCity is focused on build automation. This is implemented primarily through Projects and Build Configurations, which define Build Steps: the source control, build, and other third-party tools used to checkout, compile, and test source code.
Of course, since a build step could just be an arbitrary script, a job could be used to do anything. And thus, TeamCity could be used for anything… especially as a DevOps Swiss army knife!
But just as an all-purpose Job Scheduler would be a poor choice for build automation jobs, TeamCity is an equally poor choice for an all-purpose job scheduler. It lacks the features all other job schedulers have because it was never designed as a job scheduler.
Moreover, both job schedulers and build automation tools are poor choices for application release automation and deployment.
Deployers are Not for Deployment
One category of the built-in Build Steps is Deployers. Although the name implies that they might be used for application deployment, the intended use-case is much more limited: “Deployer build runners enable TeamCity to upload artifacts to external locations in a number of ways.”
There’s a lot more involved with deploying applications than uploading artifacts; it is not just additional automation tasks such as service stops/starts, but also process orchestration, such as approval gates, manual intervention, security, and so on.
TeamCity with BuildMaster
Although TeamCity is a poor choice for release automation, it’s definitely a proven build automation tool. This is exactly why BuildMaster has a tight integration with it; with the TeamCity extension, you can import build artifacts into BuildMaster, apply the necessary approvals, additional testing, and deploy to production.
TeamCity Terminology vs BuildMaster Terminology
| TeamCity | BuildMaster | Additional Notes |
| Projects | Applications | |
| Build Configuration | Deployment Plan | |
| Build Step | Operation | |
| Build | Release Package | |
| Build Triggers | Release Package Triggers | |
| Plugins | Extensions |
