Skip to main content

継続的インテグレーション

GitHubを使用して、GitHub Actions リポジトリにカスタムの継続的インテグレーション (CI) ワークフローを直接作成できます。

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

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

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

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

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

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

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

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

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

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

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

次のステップ

GitHub には、さまざまな言語とフレームワーク用の CI ワークフロー テンプレートが用意されています。 これらのテンプレートでの継続的インテグレーションの設定のチュートリアルについては、「コードのビルドとテスト」を参照してください。