GitHub Actions による継続的インテグレーションについて

継続的インテグレーションについて

継続的インテグレーション (CI) とは、ソフトウェアの開発においてコードを頻繁に共有リポジトリにコミットする手法のことです。 コードをコミットする頻度が高いほどエラーの検出が早くなり、開発者がエラーの原因を見つけるためにデバッグしなければならないコードの量も減ります。 コードの更新が頻繁であれば、ソフトウェア開発チームの他のメンバーによる変更をマージするのも、それだけ容易になります。 コードの記述により多くの時間をかけられるようになり、エラーのデバッグやマージコンフリクトの解決にかける時間が減るので、これは開発者にとって素晴らしいやり方です。

コードをリポジトリにコミットするとき、コミットによってエラーが発生しないように、コードのビルドとテストを継続的に行うことができます。 テストには、コードの文法チェッカー (スタイルフォーマットをチェックする)、セキュリティチェック、コードカバレッジ、機能テスト、その他のカスタムチェックを含めることができます。

コードをビルドしてテストするには、サーバーが必要です。 ローカルでアップデートのビルドとテストを行ってからコードをリポジトリにプッシュする方法もありますし、リポジトリ での新しいコードのコミットをチェックするCIサーバーを使用する方法もあります。

GitHub Actionsを使用する継続的インテグレーションについて

GitHub Actions を利用した CI では、リポジトリ中のコードをビルドしてテストを実行できるワークフローが利用できます。 ワークフローはGitHubホストの仮想マシン、もしくはあなたが自分でホストするマシン上で実行できます。 詳細については、「GitHub ホステッド ランナーの使用」および「自己ホスト ランナーの概要」を参照してください。

CI ワークフローは、GitHub イベントが発生したとき (たとえば、新しいコードがリポジトリにプッシュされたとき) や、設定されたスケジュール、またはリポジトリディスパッチ webhook を使用して外部イベントが発生したときに実行するように設定できます。

GitHub は CI テストを実行し、pull request での各テストの結果を提供するため、ユーザーはブランチの変更によってエラーが発生するかどうかを確認できます。 ワークフローのテストがすべて成功すると、プッシュした変更をチームメンバーがレビューできるように、またはマージできるようになります。 テストが失敗した場合は、いずれかの変更がその原因になっている可能性があります。

ユーザーがリポジトリで CI を設定するとき、GitHub はリポジトリ内のコードを分析し、リポジトリ内の言語とフレームワークに基づいて CI ワークフローを推奨します。 たとえば、Node.js を使っている場合、GitHub は Node.js パッケージをインストールしてテストを実行するワークフロー テンプレートを提案します。 GitHub によって提案された CI ワークフロー テンプレートを使ったり、提案されたワークフロー テンプレートをカスタマイズしたり、独自のカスタム ワークフロー ファイルを作成して CI テストを実行したりできます。

プロジェクトの CI ワークフローの設定だけでなく、GitHub Actions を使用してソフトウェア開発のライフサイクル全体に渡るワークフローを作成することもできます。 たとえば、Actionを使用してプロジェクトをデプロイ、パッケージ、またはリリースすることが可能です。 詳しくは、「ワークフローの書き込み」をご覧ください。

一般的な用語の定義については、「GitHub Actions を理解する」を参照してください。

ワークフロー テンプレート

GitHub には、さまざまな言語とフレームワーク用の CI ワークフロー テンプレートが用意されています。

GitHub.com の actions/starter-workflows リポジトリにある GitHub によって提供される CI ワークフロー テンプレートの完全な一覧を参照してください。

参考資料

• ビルドとテスト