I messed up. We're getting back to builds!
by Alex Papadimoulis, on Dec 20, 2018 12:00:00 PM
A mea culpa from Inedo Founder and CEO Alex Papadimoulis
The original vision of BuildMaster was to "automate software delivery from source code to production, by facilitating, integrating, and managing the various tools and processes." These days, we simply call this CI/CD.
But back then, this was a novel idea, especially since so few organizations were even doing build automation. And therein lay the problem: build automation used to be a complete pain. You'd have to install all these developer and component libraries on your build server. Then some build tools, source control clients, and Visual Studio (maybe even Visual Basic 6). And then a bunch of random and inexplicit configuration. Although it wasn't our mess, it was our problem because it made it that much harder to get value from BuildMaster.
All the while, dedicated CI tools like Jenkins were becoming more and more popular. They were free and open source, which meant there was a lot more tolerance (and community support) for working through challenges with third-party tools. A lot of new customers even preferred using dedicated CI tools to create their build artifacts, and then would use BuildMaster to import and deploy those artifacts.
I thought this was the future.
Even though BuildMaster was lot easier to use than CI servers, it didn't matter when wrangling build configuration was nearly impossible. So, I decided to reshape the product and instead focus on release automation that imported build artifacts from CI servers.
In BuildMaster 5.0, we began this journey by renaming "builds" to "release packages" and downplayed a lot of the build-automation related features. A lot of you noticed, and we did our best to explain the new direction. We had still planned to support build automation, but it wasn't going to be a primary use case.
I was wrong.
In the years since, build automation has gotten a heck of a lot easier. Nowadays, there's not only build tools like msbuild, gradle, and grunt, but package managers like nuget, maven, and npm. And they all "just work", at least for the most part.
All the while, dedicated CI servers have gotten more and more complicated in their quest to go beyond build automation. As a result, a lot of our users strongly preferred BuildMaster for their build automation needs, and even expanded their use despite our new product direction.
As much as it pains me to admit it, I was wrong. We should have never moved away from builds.
"Builds" are back in BuildMaster
Technically, they were never gone, but now we're investing a lot in making build automation a primary use case. Of course, we will still definitely keep import as a primary use case as well, because I think a major value that BuildMaster offers is the multiple paths of getting build artifacts:
- Import from CI Servers, ProGet, or a drop path
- Create in BuildMaster
- Manual upload
To support the "create" use case, here's what we've done so far in BuildMaster 6.1.
"Release packages" are once again called "Builds" in the UI. Admittedly, this is largely a cosmetic change (not unlike the Windows Start Menu going back to "normal size" in Windows 8.1), but it's mostly us admitting we were wrong about our new vision.
Repository Webhooks will allow you to use Gitlab or GitHub's webhook features to trigger a new build, new release, or even a deployment within BuildMaster. These are extensible, and we'll likely be adding more Webhooks for other tools down the line. You can write your own in the meantime.
Repository Monitors will periodically monitor a git repository (and its branches) for changes, and create a new build, new releases, or even deployment when a change occurs. These are a lot more flexible than our legacy SCM Triggers and also most other CI server's repository monitors because they allow you to target multiple applications instead of requiring a one-to-one ratio of projects and monitors.
The Build Reporting and Testing Running features were revamped and optimized as well. We'll continue enhancing and touching-up our build automation features throughout this release, so if you have any suggestions please don't hesitate to submit a feature request.
Thanks to everyone who encouraged this re-direction, and as always, don't hesitate to contact me directly at apapadimoulis at inedo dot com.