Should I use GitHub Actions or a self-hosted build server? – News Block

GitHub Actions is a CI/CD platform that allows developers to automatically build, test, and deploy applications on GitHub, without using external tools. As easy as it is to use, do you even need an external build server?

GitHub Actions

CI/CD is the process of automatically building and deploying applications, typically through an automated “build pipeline” that takes your code, runs the build script, and deploys it where it needs to go. Build pipelines are typically managed by third-party build server software like TeamCity, Travis CI, or Jenkins, which are industry-standard tools for managing all things CI/CD.

However, they are usually complicated to set up, which is where GitHub Actions offers an alternative for everyday coders. It is much simpler and often free for most users, and despite being a free tool, it stands up to proprietary solutions, especially with recent updates and community support.

The one-click configuration and ease of use of GitHub Actions make it a great entry-level tool for learning build automation, especially since you don’t have to set up the entire infrastructure yourself to get started, and you don’t need your own servers running 24/7 to handle builds.

Most types of apps will already have templates built, which means getting your app built automatically is usually as simple as clicking the “Actions” tab in your repository and setting up a pre-built template. GitHub may even recommend one for you based on your code base:

You can also write your own YAML configuration files, which can be used by any available Docker container and tool to build any application, both on Windows and Linux runners. These can run any type of scripts you want, including Bash/PowerShell scripts located in your repository.

One of the best features of GitHub Actions is the community marketplace, which functions as a package manager for tools frequently used in build scripts. This can save you a lot of time that you would spend on script automation yourself. For example, a common deployment tactic is to upload build artifacts to an Amazon S3 storage bucket, and there are many tools on the market that can do this for you.

Using the marketplace, GitHub Actions can do basically anything that other standalone solutions can do, just with a bit more manual effort. After all, it only runs basic scripts on a Linux or Windows system.

For example, tools like Jenkins offer integration with issue management software like Jira or Trello, or logging integrations with Slack. These are built into the software and easy to set up, and are great standalone building system selling points. However, GitHub Actions can also be configured to do all of these things by configuring marketplace tools.

One of the biggest drawbacks to GitHub Actions is the pricing structure. Each GitHub account or organization has a set number of build server minutes that are shared among all repositories. Every minute a GitHub server spends running your build uses minutes from this bucket. The free tier is 2,000 minutes, or half that for Windows, which is still more than enough for most casual users.

You can pay more for GitHub Pro, Team, or Enterprise for more minutes, but you can also avoid this problem by providing your own self-hosted broker. If you have an additional server, you can quickly configure it to accept tasks from GitHub Actions. Depending on the performance of that server, it could even be significantly faster than GitHub Action’s shared hosting. You can read our guide on how to set up your own self-hosted brokers for more information.

Overall, GitHub Actions is great for hobbyists and works well enough that most small teams won’t have a problem building their projects using the service.

External build servers

On the other hand, an external build server, such as Jenkins or TeamCity, typically provides more advanced features for building, testing, and deploying applications and is generally preferred by larger teams and corporations for greater flexibility.

If your team has many projects, it’s very helpful to have a centralized place to manage the automation and deployment of those projects. This separates the concerns of each service and allows source control to focus on hosting your code and the build server on building it.

For example, if you want to manage build scripts for many repositories, you’ll need to do so from each repository’s settings. But with a build server, you can create groups of build configurations that use the same template and make changes to the template. It’s also easier to see what’s going on with your automation in general when you have a good dashboard.

Separating the build system from source control also allows for more flexibility in choosing your tools and services. For example, if you want to use alternative source control solutions like Gitlab or BitBucket, you can easily replace them without altering your build server configuration. With GitHub Actions, you’re basically forced to use GitHub.

Standalone solutions can also use YAML-style configuration files, but generally have more built-in functionality and offer more control over steps and automation. For example, TeamCity breaks the build down into individual steps, each of which can run different scripts, actions, or executables, and can be configured with higher fidelity than a simple YAML file.

Lastly, the features and integrations that proprietary solutions offer are useful and generally nice to have. For example, TeamCity offers a custom Slack app integration, which can log build errors directly to your team.

In general, if your team has multiple projects and you care about managing them efficiently, it may be worth considering setting up your own CI/CD server.

Fortunately, many of the good CI/CD solutions are free or open source. Jenkins is completely open source, but requires self-hosting. JetBrains TeamCity is free if you are self-hosted, but they also offer a paid cloud service. Travis CI is paid only, but it is another popular solution used in the industry.

RELATED: How to build a Jenkins build server