While we haven’t come up with a theme for our next generation of products, we already have some idea of what the next major shift in our product line (BuildMaster v6, Otter v2, ProGet v5) will look like.

Not So Drastic.

The shift to the current generation was quite drastic. ProGet went from primarily a private NuGet repository to a Universal Package Manager; BuildMaster saw a brand new execution engine, new agents, and so many other changes; and of course, we launched Otter.

Tweaked User Interface.

As with previous generations of ours software -- and nearly all consumer-facing software like phones apps and desktop operating systems -- we will bring the latest UX trends into our products. Will rounded corners be back? Gradients? Hollow instead of solid icons? Who knows… but looking sharp is important, and reinforces our commitment to supporting the ever-changing software landscape.

Exportable Configuration

Although we plan to continue using an enterprise-grade database engine (primarily Microsoft SQL Server, and Postgres for now on Linux) as the reliable means to store configuration, the import/export of various configuration like [variables] and [infrastructure] has been well received. It also makes testing and supporting our products much easier.

We would love to see all product configuration importable and exportable in this same manner.

Detachable Configuration (Rafts).

In Otter, we introduced the concept of [Rafts] as a sort of detachable configuration. In addition to enabling versioned configuration, this allows for some interesting workflows, such as using Git branches to test different levels of configuration (Test, Production).

While the concept may not translate as easily as exportable configuration, we would like to use this abstract storage mechanism for more configuration, especially in BuildMaster.

More Developer-friendly APIs.

In the previous generation of our products (BuildMaster v4 / ProGet v3), we used a flexible and all-purpose API (now called the Native API) that allowed you to do nearly anything that a user may do from the web interface. However, it was a bit complex to use because it required a knowledge of the product’s internal design.

We’ve since added several endpoints that each solve different problems, and thus each operate a bit differently. This has been quite successful, but there are still a lot of areas that need APIs. We would love to see all of the product orchestrated without using the Native API.

Moving Towards Next Generation Today.

As we develop and modify existing features, we are keeping our next generation approach in mind. For example, we are continuing to add API endpoints. And as we do that, we are thinking in terms of “how might this be used in a detachable configuration”.

Addressing BuildMaster’s Legacy Code.

Like all software ever created, legacy code and functionality as a complete pain to deal with. It’s especially challenging in BuildMaster because the product underwent a major shift in version 5, and the legacy features had been already stretched to its limits after years of added-on functionality. Although we follow the “never touch anything legacy” rule, sometimes the slightest change can yield unexpected consequences.

So we have a tough choice. Either we keep the legacy code, we gut it… or we fork the product, call it something new and exciting, and then continue maintaining both products. None of the choices are great. The latter option is certainly appealing, if for no other reason than the name “BuildMaster” doesn’t quite convey Application Release Automation.