user

Self-hosted and User-friendly CI/CD with BuildMaster

Introduction

Alex Papadimoulis

Alex Papadimoulis


LATEST POSTS

CRAN (R) Feeds Come to ProGet! 27th November, 2023

ProGet Debian & Linux Feeds: A Feature Refresh 10th November, 2023

Inedo

Self-hosted and User-friendly CI/CD with BuildMaster

Posted on .

Is “the public cloud” really the best host for your CI/CD pipelines that automate builds and deployments?

Many organizations don’t think this way. Instead, they host and manage their own CI/CD tools on infrastructure they control.

In this article, I’ll talk about…

  • Why self-hosting is becoming more popular, especially in cost- and risk-conscious organizations
  • BuildMaster 2022 (and beyond), and how it’s a great option for simplifying and controlling your CI/CD processes
  • How BuildMaster compares to other self-hosted tools you may be familiar with: Jenkins, TeamCity, and Octopus Deploy

Moving away From Cloud-based CI/CD to Self-Hosting

According to Gartner, more than 90% of enterprises plan to deploy hybrid or multi-cloud strategies to minimize the risks of “putting all their eggs in one basket” and maintain control over costs, data and change,

Regarding CI/CD, the inherent security and outage risks are compounded. Cloud-based CI/CD platforms not only control all of your data, but they’re constantly delivering changes that many users don’t want or need. As anyone who has used software knows, the latest is often not the greatest.

Not everyone wants to constantly redefine their CI/CD processes, but cloud-based platforms force these changes at inconvenient times. What worked perfectly a few months ago is now a “legacy” feature that will soon be unsupported. And that means updating on their schedule, not yours.

Self-hosting CI/CD tools on your own infrastructure is a great way to avoid all this, but many vendors are moving away from self-hosting. Or at least they’re making it much harder for you to manage their tools. Years ago, upgrading simply meant a few clicks in a Windows installer; now it requires an on-premises Kubernetes cluster and all the skills that come with maintaining it.

At Inedo, we’re going in the complete opposite direction. I believe there will always be a market for self-hosted tools, and a core feature of our products is ease of self-management. I’m also not interested in building (and maintaining) a massive cloud-hosted service. Our entire focus is on self-hosted products.

Of course, BuildMaster is much more than a CI/CD tool that’s easy to self-host.

BuildMaster: A Self-Hosted CI/CD Alternative

BuildMaster is a “user-friendly CI/CD platform that can automate builds and deployments and give the entire team visibility and control over the release process.”

It’s not a “CI tool” with a deployment tacked-on, BuildMaster is designed from the ground up to take your software from source control to production following the processes you define.

Use Your Existing Tools/Processes

BuildMaster integrates with the tools and processes you use today, while giving you the flexibility to make changes and improvements. This includes:

We’re working to make all these integrations easy to configure and as seamless as possible. For example, you only need to enter your Git server credentials once, and then you’ll be guided through selecting a namespace/repository on the server, then building your code:

After you’ve connected your repository to BuildMaster, you can browse branches within BuildMaster, compare changes between builds, and navigate directly to individual commits or file changes.

Low-Code Automation with OtterScript

Of course, regardless of how you automate it, integrating all of this can get very complex. With other tools, you have to write “quasi-scripts” in a YAML syntax that never quite makes sense, while trying to contort the PowerShell commands and executables you want to run.

BuildMaster uses something much better: OtterScript and your existing scripts.

OtterScript is a low-code scripting language that has a visual and a text mode that you can freely switch between.

OtterScript is designed to handle complex multi-server automation in imperfect environments. This means that it provides the parallelism and error handling of a normal scripting language, but with the robustness of things like retries and timeouts.

You can also import your existing scripts (PowerShell, Bash, Python, Windows Batch, etc.) and run them as part of your pipeline.

Simplify Automation Tasks with Script Templates

Although OtterScript is low-code, and really easy to learn and use, it is Yet Another Scripting Language. Even “simple” things like creating a . NET Application or deploying an IIS site can become complex. That’s why we have developed Script Templates to simplify these tasks.

For example, the Build .NET Project template can compile a .NET project or solution, run a test project, track the open-source packages you’re using, and finally capture the output as an artifact to deploy later.

The Deploy IIS Site template stops an application pool, deploys a build artifact and configuration file to the server, and then restarts the application pool. It can also configure the site or application pool as needed.

Under the hood, these script templates are simply OtterScript. If you want to do more than what the script template provides, you can simply convert it and edit it as normal OtterScript.

How does BuildMaster Compare?

There are a variety of automation tools for build/deploy. Several vendors—Microsoft, Atlassian, and even JetBrains—have even created multiple tools and are effectively competing with themselves, in addition to each other and everyone else.

BuildMaster is great as a build automation server (and can replace many of these tools), but it can also integrate with CI servers to help you deploy and release build artifacts. For example, after connecting to a Jenkins project, you can browse builds, import those artifacts, and deploy them directly from BuildMaster.

We’ve written a few comparisons to help explain the similarities and differences, but in summary:

  • BuildMaster vs. Jenkins. BuildMaster is much easier to use, configure, and manage, and was designed for CI/CD from the start. However, BuildMaster can also use and control Jenkins to get the best of both tools.
  • BuildMaster vs. Octopus Deploy. BuildMaster has many similar GUI-based uses, but also offers much more powerful scripting/automation. BuildMaster is the single CI/CD tool that replaces your “Octopus Deploy Stack” of tools.
  • BuildMaster vs. TeamCity. BuildMaster’s deployment capabilities are much stronger than TeamCity’s, and you can either replace TeamCity or integrate with TeamCity to build a CI/CD pipeline.

What’s Coming in BuildMaster 2023 and Beyond

Like the rest of the market, BuildMaster has seen a lot of changes over the years. Some of the changes—like downplaying builds and creating a competing product—were huge, Windows 8-esque mistakes. None of our users asked for these changes, and they didn’t exactly solve users’ real problems.

After refocusing on users last year, we’ve been working to evolve BuildMaster to solve more of the problems our users face.

  • Self-service CI/CD; most teams don’t have an automation expert on call, making creation and troubleshooting tedious. With script templates, OtterScript, and similar features, we’ll strive to make CI/CD as easy as possible.
  • Security & Compliance in Pipelines; we’ll continue to add and improve features like manual approvals, seeing vulnerabilities and license problems in the open-source Packages & Dependencies, etc. to balance self-service
  • New Technologies & Best Practices; whether you’re just starting to consider Docker or you’re looking for a better way to deploy Kubernetes clusters, we’ll make it as easy and intuitive as possible

How to Get Started

BuildMaster is easy to download and install on Windows or Linux.

To help you learn how BuildMaster works, I’d encourage you to use (clone) the two repos on the inedo-samples GitLab repositories and then connect BuildMaster to a GitLab account. Those repositories will show you a basic .NET application, and then a more advanced NuGet Package CI/CD Pattern that works with a ProGet feed.

And as always, we’re very open to your feedback—let us know how we can continue to build a better self-hosted CI/CD platform to solve the problems you’re facing today.

Alex Papadimoulis

Alex Papadimoulis

Navigation