GitHub Actions を使用するべきですか? それともセルフホスト型ビルドサーバーを使用するべきですか?

GitHub Actions は、開発者が外部ツールを使用せずに、すべて GitHub 上でアプリケーションを自動的に構築、テスト、デプロイできるようにする CI/CD プラットフォームです。非常に使いやすいので、外部のビルド サーバーも必要ですか?

GitHub アクション

ただし、一般的にセットアップは複雑なので、GitHub Actions が日常のプログラマーに代替手段を提供します。これははるかにシンプルで、ほとんどのユーザーにとって無料であることが多く、無料ツールであるにもかかわらず、特に最近のアップデートとコミュニティ サポートにより、独自のソリューションにも耐えられます。

GitHub Actions は、ワンクリックでセットアップでき、使いやすいため、ビルドの自動化を学ぶための優れた入門レベルのツールです。特に、開始するためにすべてのインフラストラクチャを自分でセットアップする必要がなく、ビルドを処理するために 24 時間年中無休で稼働する独自のサーバー。

ほとんどの種類のアプリケーションには、すでに作成されたテンプレートが含まれています。つまり、アプリケーションを自動的に構築することは、通常、リポジトリの「アクション」タブをクリックして、事前構築されたテンプレートを構成するのと同じくらい簡単です。GitHub では、コードベースに基づいて推奨することもできます。

独自の YAML 構成ファイルを作成することもできます。これにより、Windows ランナーと Linux ランナーの両方で、任意のアプリケーションの構築に使用できるツールや Docker コンテナーを使用できます。これらは、リポジトリにある Bash/PowerShell スクリプトなど、必要なあらゆる種類のスクリプトを実行できます。

GitHub Actions の最も優れた機能の 1 つは、ビルド スクリプトでよく使用されるツールのパッケージ マネージャーのように機能するコミュニティ マーケットプレイスです。これらにより、自動化のスクリプト作成に費やす時間を大幅に節約できます。たとえば、一般的なデプロイ戦術はビルド アーティファクトを Amazon S3 ストレージ バケットにアップロードすることであり、マーケットプレイスにはそれを実行できるツールが多数あります。

マーケットプレイスを使用すると、GitHub Actions は基本的に他のスタンドアロン ソリューションで実行できることはすべて実行できますが、手作業が少し増えるだけです。結局のところ、これは Linux または Windows システム上で基本的なスクリプトを実行しているだけです。

たとえば、Jenkins などのツールは、Jira や Trello などの問題管理ソフトウェアとの統合、または Slack とのログ統合を提供します。これらはソフトウェアに組み込まれており、セットアップが簡単であり、スタンドアロン ビルド システムの大きなセールス ポイントです。ただし、マーケットプレイスからツールを構成することで、GitHub Actions をセットアップしてこれらすべてのことを実行することもできます。

GitHub Actions の最大の欠点の 1 つは、価格体系です。各 GitHub アカウントまたは組織には、すべてのリポジトリ間で共有されるビルド サーバーの分数が設定されています。GitHub サーバーがビルドの実行に費やすごとに、このバケットからの分が使用されます。無料利用枠は 2000 分で、Windows の半分ですが、ほとんどのカジュアル ユーザーにとってはそれでも十分です。

GitHub Pro、Team、Enterprise では、より多くの分を使用するために追加料金を支払うことができますが、独自のセルフホスト ランナーを提供することで、この問題を完全に回避することもできます。追加のサーバーが存在する場合は、GitHub Actions タスクを受け入れるようにすぐに構成できます。サーバーのパフォーマンスによっては、GitHub Action の共有ホスティングよりも大幅に高速になる場合もあります。詳細については、独自の自己ホスト ランナーの設定に関するガイドをご覧ください。

全体として、GitHub Actions は愛好家にとって素晴らしいものであり、ほとんどの小規模チームがサービスを使用してプロジェクトを構築するのに問題がないほど十分に機能します。

外部ビルドサーバー

一方、Jenkins や TeamCity などの外部ビルド サーバーは、通常、アプリケーションの構築、テスト、デプロイのためのより高度な機能を提供し、柔軟性が高いため、大規模なチームや企業に好まれます。

チームに多くのプロジェクトがある場合、それらのプロジェクトの自動化と展開を一元管理できる場所があると非常に便利です。これにより、各サービスの関心事が分離され、ソース管理はコードのホストに集中し、ビルド サーバーはコードのビルドに集中できるようになります。

たとえば、多くのリポジトリのビルド スクリプトを管理したい場合は、各リポジトリの設定から管理する必要があります。ただし、ビルド サーバーを使用すると、すべて同じテンプレートを使用するビルド構成のグループを作成し、テンプレートに変更を加えることができます。また、優れたダッシュボードがあると、一般的に自動化で何が起こっているかを確認しやすくなります。

ビルド システムをソース管理から分割することにより、ツールとサービスをより柔軟に選択できるようになります。たとえば、Gitlab や BitBucket などの代替ソース管理ソリューションを使用したい場合は、ビルド サーバーの構成を変更することなく、それらを簡単に置き換えることができます。GitHub Actions を使用すると、基本的に GitHub の使用に制限されます。

スタンドアロン ソリューションでも YAML スタイルの構成ファイルを使用できますが、通常はより多くの機能が組み込まれており、ステップと自動化をより詳細に制御できます。たとえば、TeamCity はビルドを個別のステップに分割し、それぞれで異なるスクリプト、アクション、または実行可能ファイルを実行でき、単純な YAML ファイルよりも高い忠実度で構成できます。

最後に、独自のソリューションが提供する機能と統合は便利であり、一般に便利です。たとえば、TeamCity はカスタム Slack アプリ統合を提供しており、ビルド エラーをチームに直接記録できます。

全体として、チームに複数のプロジェクトがあり、それらの効率的な管理に関心がある場合は、独自の CI/CD サーバーのセットアップを検討する価値があるかもしれません。

幸いなことに、優れた CI/CD ソリューションの多くは無料またはオープンソースです。Jenkins は完全にオープンソースですが、セルフホスティングが必要です。JetBrains TeamCity はセルフホスティングの場合は無料ですが、有料のクラウド サービスも提供しています。Travis CIは有料のみですが、業界で使用されているもう 1 つの人気のあるソリューションです。