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

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

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

GitHub Actions is currently in limited public beta and is subject to change. We strongly recommend that you do not use this feature for high-value workflows and content during the beta period. For more information about the beta, see "About GitHub Actions."

For more information about using GitHub Actions, see "Automating your workflow with GitHub Actions."

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

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

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

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

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

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

CIでGitHub Actionsを使用すると、リポジトリでコードをビルドしたうえで、GitHubにホストされたサーバーでテストを実行するデフォルトのワークフローが作成されます。 ワークフローはクラウドにホストされたサーバー上の仮想環境で実行され、リポジトリのクローンにアクセスすることができます。 詳細については、「[ GitHub Actions

](/articles/virtual-environments-for-github-actions/)の仮想環境」を参照してください。

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

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

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

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

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

サポートされている言語

GitHubでは、各種の言語とフレームワークに応じてCIワークフローが提供されます。

GitHub で提供されるCIワークフローの詳細なリストは、actions/starter-workflowsリポジトリにあります。

GitHub Actionsを使用する継続的インテグレーションのコア概念

GitHub Actionsで継続的インテグレーションを使用するときに特別な意味を持つ一般用語があります。

ワークフロー

GitHubで任意のプロジェクトをビルド、テスト、パッケージ、リリース、またはデプロイするためにリポジトリでセットアップできる、設定可能な自動プロセスです。 ワークフローは1つ以上のジョブから構成され、スケジュールしたり、イベントに応じて動作させたりできます。

ワークフローラン

事前設定されたイベントが生じたときに実行されるワークフローのインスタンス。 それぞれのワークフローランについて、ジョブ、アクション、ログ、ステータスを見ることができます。

ワークフローファイル

最低1つのジョブと合わせてワークフローの設定を定義するYAMLファイル。 このファイルは、GitHubリポジトリの.github/workflowsディレクトリ直下にあります。

ジョブ

ステップから構成される定義されたタスク。 各ジョブは、仮想環境の新しいインスタンスで実行されます。 ジョブ我の実行に関する依存関係のルールを、ワークフローファイル内で定義できます。 ジョブは同時に並列に実行することも、以前のジョブのステータスに応じてシーケンシャルに実行することもできます。 たとえば、ワークフローにコードのビルドとテストという2つのシーケンシャルなジョブを持たせ、テストジョブをビルドジョブのステータスに依存させることができます。 ビルドジョブが失敗した場合は、テストジョブは実行されません。

ステップ

ステップは、ジョブが実行するタスクの集まりです。 ジョブ中の各ステップは同じ仮想環境で実行されるので、ファイルシステムを使用して、そのジョブにおける複数のアクションで情報を共有することが可能です。 ステップでは、コマンドもしくはアクションを実行できます。

アクション

ステップとして組み合わせてジョブを作成するための、個々のタスクです。 アクションは、ワークフローの最小のポータブルな構成要素です。 GitHubコミュニティから共有されるアクションを使って独自にアクションを作成することも、パブリックなアクションをカスタマイズすることもできます。 ワークフローでアクションを使うには、それをステップとして含めなければなりません。

継続的インテグレーション(CI)

頻繁に小さなコード変更を共有リポジトリにコミットするソフトウェア開発のプラクティス。 GitHub Actionsを使えば、コードを自動的にビルドしてテストするカスタムのCIワークフローを作成できます。 リポジトリからコード変更のステータスと、ワークフロー内の各アクションの詳細なログを見ることができます。 CIは、コード変更に対する即座のフィードバックを提供し、素早くバグを検出して解決できるようにすることによって、開発者の時間を節約します。

継続的デプロイメント(CD)

継続的デプロイメントは、継続的インテグレージョンの上に構築されます。 新しいコードがコミットされ、CIテストをパスしたなら、そのコードは自動的に実働環境にデプロイされます。 GitHub Actionsを使えば、コードを任意のクラウド、自己ホストのサービスやプラットフォームに、リポジトリから自動的にデプロイをするカスタムのCDワークフローを作成できます。 CDは、デプロイメントのプロセスを自動化し、テスト済みの安定したコード変更を顧客により早くデプロイすることによって、開発者の時間を節約します。

仮想環境

GitHubは、ワークフローを実行するためのLinux、macOS、Windowsの仮想環境をホストします。

ランナー

各仮想環境で実行できるジョブを待つGitHubのサービスです。 ランナーは、ジョブを選択するとそのジョブのアクションを実行し、進行状況、ログ、最終結果の報告をGitHubに返します。 ランナーは一度に1つのジョブを実行します。

イベント

ワークフローの実行をトリガする特定のアクティビティ。 たとえば、誰かがコミットをリポジトリにプッシュした場合、あるいはIssueもしくはプルリクエストが作成された場合、GitHubからアクティビティを発生させることができます。 また、リポジトリのディスパッチwebhookを使って外部イベントが生じたときにワークフローが実行されるよう設定することもできます。

アーティファクト

アーティファクトとは、コードをビルドしてテストするときに作成されるファイルのことです。 たとえば、アーティファクトには、バイナリまたパッケージファイル、テスト結果、スクリーンショット、ログファイルなどがあります。 アーティファクトは、それを作成したワークフローの実行に関連づけられ、他のジョブから使ったり、デプロイしたりできます。

ワークフロー実行の通知

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

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

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

Status badges show whether a workflow is currently failing or passing. A common place to add a status badge is in the README.md file of your repository, but you can add it to any web page you'd like. Badges display the status of your default branch (usually master).

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

参考リンク

](/articles/setting-up-continuous-integration-using-github-actions)を使用して継続的インテグレーションを設定する

担当者にお尋ねください

探しているものが見つからなかったでしょうか?

弊社にお問い合わせください