GitHub Actions is a CI/CD platform that enables developers to automatically build, test, and deploy applications all on GitHub, without using any external tools. With how easy 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 usually managed by external build server software like TeamCity, Travis CI, or Jenkins, which are industry-standard tools for managing everything related to CI/CD.
They’re generally complicated to set up though, 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 the proprietary solutions, especially with recent updates and community support.
The one-click setup and ease of use of GitHub Actions makes it a great entry-level tool for learning build automation, especially since you don’t have to set up all the infrastructure yourself to get started, and you don’t need your own servers running 24/7 to handle the builds.
Most types of applications will have templates already made, which means getting your application automatically building is usually as simple as clicking on the “Actions” tab on your repository and configuring a prebuilt template. GitHub can even recommend one to you based on your codebase:
You can also write your own YAML configuration files, which are able to use any tools and Docker containers available to build any application, on both Windows and Linux runners. These can run any kind 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 like a package manager for tools often used in build scripts. These can save you a lot of time that would be spent scripting automation yourself. For example, a common deployment tactic is uploading build artifacts to an Amazon S3 storage bucket, and there are many tools on the marketplace that can do that for you.
Using the marketplace, GitHub Actions can do basically anything other standalone solutions can, just with a little more manual effort. After all, it is just running 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 in to the software and easy to set up, and they’re great selling points of standalone build systems. However, GitHub Actions can also be set up to do all these things by configuring tools from the marketplace.
One of the biggest drawbacks of GitHub Actions is the pricing structure. Each GitHub account or organization has a set number of build server minutes that is shared across all repositories. Every minute that a GitHub server spends running your build uses minutes from this bucket. The free tier is 2000 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 circumvent this issue altogether by providing your own self-hosted runner. If you have an extra server lying around, you can pretty quickly configure it to accept GitHub Actions tasks. Depending on the performance of that server, it might even be significantly faster than GitHub Action’s shared hosting. You can read our guide about setting up your own self-hosted runners to learn more.
Overall, GitHub Actions is fantastic for hobbyists and works well enough that most small teams would have no issues building their projects using the service.
External Build Servers
On the other hand, an external build server, such as Jenkins or TeamCity, usually provides more advanced features for building, testing, and deploying applications, and is typically preferred by larger teams and corporations for having greater flexibility.
If your team has a lot of projects, having a centralized place to manage the automation and deployment of those projects is very useful. This separates the concerns of each service and allows the source control to focus on hosting your code, and the build server on building it.
For example, if you want to manage the build scripts for many repositories, you’ll have to do so from each repository’s settings. But with a build server, you can create groups of build configurations that all use the same template, and make changes to the template. It’s also just easier to see what’s going on with your automation in general when you have a nice dashboard
Splitting the build system from source control also allows greater 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 those without messing with any of your build server configuration. With GitHub Actions, you’re basically locked in to using GitHub.
Standalone solutions can also use YAML-style configuration files, but usually have more features built in and offer greater control over the steps and automation. For example, TeamCity breaks down the build into individual steps, which each can run different scripts, actions, or executables, and can be configured with greater 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 custom Slack app integration, which can log build errors directly to your team.
Overall, if your team has multiple projects and cares about efficient management of them, it may be worthwhile to look into setting up your own CI/CD server.
Luckily, plenty 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’re self hosting, but also offers a paid cloud service. Travis CI is paid only, but is another popular solution used in the industry.
RELATED: How to Build a Jenkins Build Server
Source link
