How does BuildMaster compare to Team Foundation Server?
June 6, 2011 1 Comment
We’re often asked how BuildMaster and Microsoft Team Foundation Server compare, especially given that, in theory, TFS could do most of what BuildMaster does.
The fact is anything can do what BuildMaster does if you modify / customize/ add-on enough. Literally, anything: Subversion, Microsoft Word, or even COBOL. After all, BuildMaster is just software, not magic.
When considering how good of a fit any tool is for a problem, there are three important things to consider.
- What was the tool designed to do, and what do you get out-of-the-box?
- How much work will be involved in adapting the tool to solve the problem?
- What will the ongoing costs be in maintaining the adaptations as business requirements and the underlying platforms change?
Depending on what the problem is, any of the aforementioned tools (TFS, BuildMaster, Subversion, Word, and COBOL) could be a near-perfect fit. But none of them are designed to do the same things, and therefore cannot solve all problems.
That said, comparing TFS to BuildMaster is like comparing apples to pie à la mode. There’s a relation and a little overlap, but they are fundamentally different things. Obviously, a good chef could turn the former to the latter at a cost of time and money… but if you just need to serve pie for a dessert, spending eight bucks to buy a pie is easier.
Team Foundation Server is a great tool, and it was designed to solve the following problems:
- Source Control – full-featured enterprise SCM
- Project Tracking – including status reports, etc. on various issues
- Issue Management – assign tasks and work items to developer
A separate product, TeamBuild, is a build server application designed to perform continuous integration on projects inside of TFS. It introduces the concepts of “builds” and executes msbuild scripts to do the legwork. But that’s where it stops – for everything else, you will need a plug-in, either by customizing TeamBuild or by writing msbuild scripts.
Consider, for example, deployment in TFS. The most commonly used mechanism is a free and open-source project called TFSDeploy. It works by installing a Windows Service that monitors the various builds created by TeamBuild; when the “build quality” field changes (e.g. from “development” to “ready for testing”), it runs the “ready for testing” msbuild script for that project.
It’s a good start, and assuming you can write an epic msbuild script that does everything across all servers, there are still a lot of questions that need to be answered. Here are just a few:
- How do you prevent just anyone from changing that field?
- How could you restrict someone to only change it from “development” to “test”, and someone else from “test” to “production”?
- What if you accidently change it from “development” to “production”?
- How do you track who changed that field?
- What if the msbuild script fails and you want to go to production again?
- How do you get the script to pick up things like database change scripts and configuration files?
- Where do you document how to get the script to pick up those changes?
- How to you manage unscriptable changes? All of these questions and concerns can be answered with sufficient customizations and/or indifference. But they’re just the tip of the iceberg, and address only a single facet (“deployments”) in the application lifecycle.
BuildMaster, on the other hand, was designed to automate and facilitate the entire application lifecycle. There are plenty of problems that we don’t solve, and never will. Take Source Control and Issue Tracking, for example: given the plethora of already-available options (such as TFS), we believe it’s best to integrate instead of reinvent.
Our focus is on automation and facilitation of application development, and there are a lot of components to this process. To name a few:
- Application Portfolio Management – a central “hub” for all in-house applications to provide a unified view and status; also tracks the history of what happened to applications and the individuals responsible
- Deployables and Dependency Management – a “deployable” is a high-level, architectural component of an application (e.g. a framework, Windows Service, database, etc.) that depends upon other deployables
- Release Management – maintains the state of releases and related builds as they progress throughout different development environments
- Approvals / Sign-offs – a workflow-based process which defines the sign-offs/approvals necessary for promotion to environments, allows users to approve/sign-off as needed, and tracks the history
- Build Management / Continuous Integration – a set of tools and components that are responsible for generating “artifacts” by integrating with source control
- Artifact Library – stores build artifacts and provides a mechanism for secure retrieval and archiving
- Database Change Management – processes and tools that enable database changes to propagate side-by-side with code deployments
- Configuration File Management – processes and tools that enable configuration file changes to propagate side-by-side with code deployments
- Change Control – processes and tools that enable all other changes to propagate side-by-side with code deployments
- Deployment Procedure/Plan Library – a centralized system that maintains all of the deployment procedures and plans for each application and each environment
- Deployments – automates the installation, configuration, and distribution of software components to the necessary servers
- Notifications – allows various users to define how they wish to be notified, and sends out notifications via the appropriate channels
- Auditing – keeps track of all activity and changes to the processes and procedures relevant to software development
- Security – defines and enforces which principals (users or groups) have access to which parts of the system
- 3rd-party Tool Integration – utilizes official or un-official API to allow for development tools to integrate seamlessly in the process
- Secure Server Integration – locking-down the access such that only the relevant tools/processes can access servers as needed
And again, given enough time and resources, systems to manage all of these processes can be developed in-house. Or, the processes could be manually handled (e.g. sending an email if a build can be promoted), or not at all.
Of course, up to this point, we’ve only talked about building a system to automate/facilitate a process. Next it’s important to consider the work that will go into configuring the system for a particular application, and then using that system once it’s configured.
We believe (as do our clients) that BuildMaster is a system that’s not only ready “out of the box”. It’s not only easier to configure with your applications (we have a rich UI and smart actions like “Convert Project References to File References”), but it’s easier to use day-in and day-out. And, like most vendor tools, we’re constantly improving and adding features.