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

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

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

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

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

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

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

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

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

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

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

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

スターター ワークフロー

GitHub Enterprise Server からは、さまざまな言語とフレームワークの CI スターター ワークフローが提供されます。

お使いの GitHub Enterprise Server インスタンス の actions/starter-workflows リポジトリにある GitHub によって提供される CI スターター ワークフローの完全な一覧を参照してください。