A Comparison: BuildMaster vs Azure DevOps
BuildMaster and Azure DevOps are both CI/CD process tools that aim to model and automate end-to-end CI/CD, starting by building source code and ending with the software release. Both programs are popular and are often used together as part of a modern DevOps toolchain. But, there are significant differences between the programs that impact developers’ productivity.
Origin Stories
BuildMaster was designed for one purpose – joining continuous integration with continuous delivery in order to build a self-service release platform that allows different teams to manage their own applications, deploy to their chosen environments, and at the pace the business demands. BuildMaster has remained true to its purpose since its creation.
In contrast, Azure DevOps is the newest iteration of a platform that is a hodgepodge of original code, acquired software, and ever-changing features that is popular for its original code’s strengths – software project management through integrated issue tracking and version control. It began as TFS and it was great, but it has suffered four different branding campaigns in the past five years (TFS, Visual Studio Online, Visual Studio Team Services, AzureDevOps). Across the developer community, the complaints are the same: Azure DevOps feels like a product that doesn’t know what it wants to be. Luckily though, even after all the changes, the program’s core strengths remain.
Is it an Upgrade or a Whole New Program?
When Microsoft rebranded their software from Visual Studio Team Services (VSTS) to Azure DevOps last year, their users were “upgraded” to a program that, in reality, was a brand new product. Users of the on-prem version (TFS, VSTS, Azure DevOps Server) were able to choose when to “upgrade” but after the upgrade, many users felt their needs for project hosting had become an afterthought. The new product deviated from its mission: CI/CD.
For cloud-based users, the change happened automatically. This included new URLs (abc.visualstudio.com to dev.azure.com/abc) and a new user experience. Though Microsoft offered to continue to iterate the platform based on user feedback, users were put in the position of having to beta-test the new platform while using it for DevOps pipelines at the same time.
In contrast to this forced, top down and blackbox approach, BuildMaster’s upgrades are incremental improvements to the functionality of the program based on smarter tech and feedback from developers. Further, Inedo has never and will never thrust a Buildmaster upgrade onto users. We develop programs to perform better, but our users get to choose when the upgrade happens and plan accordingly.
UI makes a Difference
One example of the problems Azure’s top down, unaccountable approach creates is its new UI. This “improvement” is frustrating developers around the world because it prioritizes a pretty interface at the expense of functionality. Developers want a power tool, not a Twitter-like interface where functions are hidden. At Inedo, developers designed BuildMaster for developers. The UI is intuitive and powerful because it was developed by true users.
Pipeline Differences
Another example of the difference in approach is that while both platforms use the idea of pipelines, only BuildMaster combines the build and deployment processes into a single pipeline. Unlike in Azure, deployment “packages” (whether artifacts, containers, or other) in BuildMaster have their full lifecycle known at their inception. Having this single pipeline is critical streamlining that allows developers to automate building, automate testing, and quickly verify to deliver ideas to production.
Build/Deployment
Each platform also handles build/deployment, including operations such as downloading artifacts, publishing, or executing scripts, in slightly different but important ways. In Azure DevOps, tasks may be selected in the web UI or defined in YAML but the choices are limited.
BuildMaster on the other hand uses operations, which may be drag/dropped via the plan editor, or defined in a domain-specific language known as OtterScript, a text-based representation of the Inedo Execution Engine. This allows users more control and the ability to tailor options in the build-deployment phase. The overall effect is like the difference between a drop-down menu and a text box; one is limited to a preset of choices while the other offers the freedom to write in whatever you need.
In addition, BuildMaster also created an execution engine that allows common deployment operations to be declared with a simple syntax that enables powerful deployment functionality including:
- Error handling: try/catch known, acceptable failure conditions
- Parallel deployment:
with async {}blocks can break up parallelizable deployment tasks - Retries:
with retry = 5 {}blocks can automatically retry operations that may rely on the status of third-parties (e.g. timestamping during code signing) - Server context:
for server {}blocks can easily switch agent context to execute code remotely on an alternate server even when the pipeline specifies a different one (don’t worry; this can be secured by environment)
Cost is Known or Unknown
Despite what Microsoft would have you believe, Azure DevOps is not free. Of course, neither is BuildMaster, but the difference is that BuildMaster’s pricing is transparent and designed to provide value – not incrementally lead you into make more and more purchases.
Consider that although Azure DevOps Services (cloud-based version) lets users download the program for free, it limits access to 5 users. Then for larger teams, the cost ranges from $30 per month (10 users) to $6,150 per month (1,000 users). The effect is no different than a free-to-download app with in-app purchases – you start off thinking it’s free, make a few incremental purchases, and then discover you’re paying for software that your company didn’t budget.
Azure DevOps Server (on-prem version) costs also shift frequently, but as of this writing, the fee is per user for basic features (like Code or Agile Planning). If users have a Visual Studio subscription, then they have the Basic features for “free” as part of the subscription, which then has various monthly fees baked into it based on number of users, pipelines, and features.
In stark contrast, BuildMaster has an upfront cost and that’s it. All features are included and you will never pay for an upgrade. You can plan the cost instead of thinking you’re getting something for free and then realizing you’re not.
Corporate Philosophy
Inedo’s tools maximize developer time, minimize release risk, and empower stakeholders to bring their vision to life faster. All with the people and technology you have right now. Our commitment is that you will never be subject to forced upgrades or sudden feature changes. You are free to deploy where you want and when you want.
A down-to-earth developer who loves programming and is still reachable on his cell phone by his clients founded Inedo. As a smaller company, Inedo is more responsive and adaptive to customer needs. At Inedo, we remain agile and responsive to the needs and opinions of developers.
Microsoft however, is a corporate monolith with multiple priorities. They have great products but their DevOps tool has some flaws and unpredictable changes. Azure DevOps is still excellent at software project management through integrated issue tracking and version control, which BuildMaster does not do. But it lacks the control and attention to users required to makes DevOps processes work as efficiently as possible.
Luckily, you don’t have to choose between them. Using BuildMaster with Azure DevOps is an opportunity to use the best that Azure DevOps has to offer and benefit from the superior CI/CD functionality of BuildMaster.
Azure DevOps with BuildMaster
Azure DevOps remains a powerful option for hosting your projects, specifically the source control and issue tracking. Because of this, BuildMaster has a tight integration with Azure DevOps.
Using the Azure DevOps extension, you can import cloud-stored build artifacts into BuildMaster, create or comment on work items, and apply the necessary automated or manual approvals, ultimately adding a layer of consistency that applies to both legacy and greenfield applications.
Terminology Comparison
| Azure DevOps | BuildMaster | Additional Notes |
|---|---|---|
| Agent | Inedo Agent | |
| Agent Pool | Resource Pools | |
| Artifacts | ProGet Feed | While BuildMaster can create and store artifacts itself, our other product ProGet is most equivalent to Azure Artifacts |
| Build Pipeline | Plans or Pipelines | |
| Build Retention | Retention Policies | |
| Build Triggers | Repository Monitors & Webhooks | |
| Deployment Group | Pipeline Stage Targets | Both systems can target servers, VMs, and other services |
| Expressions/Conditions | OtterScript | |
| Jobs | Executions | |
| Key Vault | Resource Credentials | |
| Library Variable Groups | Configuration Variables | This also relates to variables in Release Templates |
| Marketplace | Inedo Den | |
| Pre-deployment Conditions | Approvals | |
| Release Pipeline | Plans or Pipelines | |
| Tasks | Plan Operations | |
| Task Group | Module | |
| Templates | Plans or Module | A deployment plan designed to be reusable would also function the same as an template |
| Work Items | Issues |
