ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

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

GitHub Actions で GitHub リポジトリにカスタム継続的インテグレーション(CI)ワークフローと継続的デプロイメント(CD)ワークフローを直接作成できます。

GitHub ActionsはGitHub Free、GitHub Pro、GitHub FreeのOrganization、GitHub Team、GitHub Enterprise Cloud、GitHub Oneで利用できます。 GitHub Actionsは、レガシーのリポジトリごとのプランを使っているアカウントが所有しているプライベートリポジトリでは利用できません。

ここには以下の内容があります:

GitHub Actions の支払いを管理する GitHubは、macOSランナーのホストにMacStadiumを使用しています。

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

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

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

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

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

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

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

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

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

提案された継続的インテグレーションテンプレートのスクリーンショット

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

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

サポートされている言語

GitHub Enterprise Server では、各種言語およびフレームワークに応じて CI ワークフローテンプレートが提供されます。

your GitHub Enterprise Server instance 上の actions/starter-workflows リポジトリで GitHub Enterprise Server が提供する CI ワークフローテンプレートの完全なリストを参照します。

ワークフロー実行の通知

GitHub Actionsに対するメールあるいはWeb通知を有効化すると、あなたが起動したワークフローランが完了すると通知されます。 この通知には、ワークフローランのステータス(成功、失敗、ニュートラル、キャンセルされたランが含まれます)が含まれます。 ワークフローランが失敗したときにだけ通知を受けるようにすることもできます。

リポジトリのActionsタブでワークフローランのステータスを見ることもできます。 詳細については、「ワークフロー実行の管理」を参照してください。

ワークフロー実行のためのステータスバッジ

A status badge shows whether a workflow is currently failing or passing. ステータスバッジを追加する一般的な場所は、リポジトリのREADME.mdファイル中ですが、任意の好きなWebページに追加できます。 By default, badges display the status of your default branch. 特定のブランチやイベントに対するワークフローの実行のステータスを、URL中のbranch及びeventクエリパラメータを使って表示することもできます。

example status badge

詳細は「ワークフローの設定」を参照してください。

参考リンク

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.