GitHub Actionsを使うことで、コードのビルドやテストを自動で実行できます。
今回は、Visual StudioとGitHub Actionsを用いて、リポジトリにコードをプッシュしたタイミングで、自動的にビルドとテストを行う方法を解説します。
続編では、ビルド後にAzureへ自動デプロイする方法も紹介する予定です。
前提条件
GitHub Actionsを使う前に、以下を用意してください。
- Visual Studio 2022
- GitHubアカウント
また、Visual StudioとGitHubが正しく連携していることを確認します。
Visual Studioの右下にある[Git変更]タブで、コミットやプッシュが可能な状態になっていればOKです。
もしGitHubとの連携ができていない場合は、以下の記事を参照して設定してください。
Visual Studio 2022とGitHubの連携方法 | hiranote
GitHub Actionsの基本概念
GitHub Actionsは、GitHub上で自動的に処理を実行できる機能です。
例えば、次のような自動化が可能です。
- コードがリポジトリにプッシュされたら、自動でビルドとテストを実行
- プルリクエストが作成されたら、コードチェック（Lint）を行う
- ビルドが成功したら、自動でAzureやAWSにデプロイする
GitHub Actionsの構造
GitHub Actionsは、大きく次の3つの要素で構成されています。
- Workflow（ワークフロー）
自動化の全体的な流れを定義したYAMLファイル。リポジトリの.github/workflowsフォルダに配置します。 - Job（ジョブ）
Workflow内のまとまりのある処理単位。実行するOSや環境を指定できます。 - Step（ステップ）
Jobを構成する個々の処理。コマンドを実行したり、既存のアクションを利用したりします。
この3つが組み合わさり、「どのタイミングで」「どの環境で」「何を実行するか」が決まります。
GitHub Actionsの料金
GitHub Actionsは、パブリックリポジトリでは完全無料で利用できます。
プライベートリポジトリの場合も、GitHub Freeプランには月2,000分までの無料枠があり、小規模なビルドやテストであれば十分に収まります。
無料枠を超えると、追加分は従量課金（1分ごと）となります。料金は実行環境（OS）ごとに異なり、Linuxが最も安く、macOSが最も高くなります。
料金の詳細は以下の公式ページを参照してください。
GitHub Actions の課金 – GitHub Docs
プロジェクトをGitHubにプッシュ
まずはVisual Studioから、新しくサンプルプロジェクトを作成します。
今回はビルドとテストの両方が行える簡単なコンソールアプリを例にします。
サンプルプロジェクトの作成手順
- Visual Studio 2022を開き、[新しいプロジェクトの作成] を選択
- 「コンソール アプリ」（C#）を検索して選択
- プロジェクト名を
MyApp、ソリューション名もMyAppに設定- 「ソリューションとプロジェクトを同じディレクトリに配置する」のチェックを外す（OFFにするとソリューションとプロジェクトが別フォルダに分かれ、後で他のプロジェクトを追加しやすくなります）
- フレームワークは.NET 8を選択
- プロジェクト作成後、ソリューションエクスプローラーでソリューションを右クリック → [追加] → [新しいプロジェクト]
- 「xUnit テスト プロジェクト」を選択し、プロジェクト名を
MyApp.Testsに設定（.NET 8） - テストプロジェクト作成後、
MyApp.Testsプロジェクトの「依存関係」を右クリック→ [プロジェクト参照の追加] →MyAppをチェックON→[OK]をクリック
最終的に以下のようになっていればOKです。
コード例
簡単な計算を行うCalculatorクラスとそのユニットテストであるCalculatorTestsクラスを、それぞれのプロジェクトに追加し、以下のコードを貼り付けてください。
MyApp/Calculator.cs
namespace MyApp;
public class Calculator
{
public int Add(int a, int b) => a + b;
public int Subtract(int a, int b) => a - b;
}MyApp.Tests/CalculatorTests.cs
namespace MyApp.Tests;
public class CalculatorTests
{
[Fact]
public void Add_ReturnsCorrectSum()
{
var calc = new Calculator();
Assert.Equal(5, calc.Add(2, 3));
}
[Fact]
public void Subtract_ReturnsCorrectDifference()
{
var calc = new Calculator();
Assert.Equal(1, calc.Subtract(3, 2));
}
}また、テストプロジェクトにある既存の「UnitTest1.cs」クラスは不要なので削除してください。
最終的な構成は以下の通りです。
ローカルでテストが成功することを確認
GitHubにプッシュする前に、ローカルでテストが正常に動作することを確認しておきましょう。
- Visual Studio 上部のメニューから [テスト] → [すべてのテストを実行] を選択
- [テスト エクスプローラー] に「成功」と表示されることを確認
以下のように表示されればOKです。
GitHubにプッシュする
それではローカルとGitHub上にリポジトリを作成し、作成したプロジェクトをプッシュします。
Visual Studioの右下の [Git変更]タブ（または上部メニューの [表示] → [Git変更]）を開き、[Gitリポジトリの作成] を選択します。
任意のリポジトリ名（例：myapp-sample）を入力し、表示範囲はpublicにしておきます。
[作成してプッシュ] を押すと、GitHubにコードがアップロードされます。
プッシュが成功すると次のように表示されます。
プッシュ後、GitHubのRepositoriesを開き、MyApp と MyApp.Tests が存在することを確認してください。
ビルド＆テストのワークフロー作成
リポジトリにpushできたら、GitHub Actionsのテンプレートからワークフローファイルを追加します。
今回は.NETのビルド＆テストを自動化する最小構成を使います。
.NETテンプレートからワークフローファイルを生成する
GitHubで先ほどのリポジトリを開き、メニューの [Actions] をクリックします。
検索ボックスに .NET と入力し、一覧から [.NET] の [Configure] をクリックします。
.NETテンプレートの中身が表示されるので、右上の [Commit changes] を押します。
ダイアログが表示されるので、[Commit changes] をクリックしてください。
.github/workflows フォルダにdotnet.yml が生成されました。
ローカルでワークフローファイルを確認
Visual Studio上で生成したワークフローファイルの中身を確認してみましょう。
[Git変更] でプルを実行して最新を取得します。
ワークフローファイルはソリューションビューでは見れないので、フォルダービューに切り替えます。
ソリューションエクスプローラー左上の「ソリューションと利用可能なビューとの切り替え」アイコンをクリックします。
フォルダービューで展開すると.github/workflows フォルダの中身を確認できます。
ワークフローファイルの基本構造を理解する
GitHub Actionsのワークフローファイルは、YAMLという書式で書かれています。最初は見慣れないかもしれませんが、ポイントを押さえればすぐに理解できます。
以下は今回使うテンプレートの内容です。主要な部分にコメントを追加しています。
# ワークフローの名前（GitHubのActionsタブで表示される）
name: .NET Build and Test
# ワークフローを起動するタイミングを定義（トリガー）
on:
push: # コードをpushしたとき
branches: [ "master" ] # masterブランチに対してのみ実行
pull_request: # プルリクエストを作成/更新したとき
branches: [ "master" ]
# 実行する処理の定義
jobs:
build: # ジョブのID（任意の名前でOK）
runs-on: ubuntu-latest # 実行するOS環境（Linuxの最新版で実行）
steps: # ジョブの中で行う処理のステップ
# リポジトリのソースコードを取得
- uses: actions/checkout@v4
# .NET SDK (.NET 8) のセットアップ
- name: Setup .NET
uses: actions/setup-dotnet@v4
with:
dotnet-version: 8.0.x
# NuGetパッケージの復元（ダウンロード）
- name: Restore dependencies
run: dotnet restore
# プロジェクトをビルド（--no-restoreでrestoreを省略）
- name: Build
run: dotnet build --no-restore
# 単体テストを実行（verbosityはログの詳細度でnormalは標準的なログ出力）
- name: Test
run: dotnet test --no-build --verbosity normal各要素の意味について簡単にまとめます。
name：ワークフローの名前。GitHubのActionsタブにそのまま表示されます。on：ワークフローのトリガー条件。pushやpull_requestなどのイベントで動きますjobs：ワークフローの中で実行する処理のまとまり。ここではbuildというジョブが1つだけ定義されています。runs-on：ジョブを実行するOS環境を指定。Linuxが最も安価steps：ジョブの中で順番に実行する手順uses:GitHub Actionsに用意されているアクションを利用するrun:コマンドを直接実行する
これがGitHub Actionsワークフローファイルの基本構造です。
最初はテンプレートをそのまま使えばOKですが、慣れてきたら自分のプロジェクトに合わせて編集できるようになります。
GitHub Actions ワークフローの実行と結果確認
masterブランチにプッシュすると、ワークフローが自動的に動きます。
試しに何かファイルを修正してプッシュしてみてください。
プッシュ後に、GitHubの[Actions]タブでワークフローの実行履歴が一覧できます。さらに対象のコミットメッセージをクリックすると、ワークフローの詳細を見ることができます。
詳細画面ではジョブ名の「build」が表示されています。
さらにジョブ名をクリックするとステップごとの実行履歴が確認できます。
エラーメッセージや失敗したステップが表示されるので、ワークフロー実行が失敗した際の原因特定に役立ちます。
まとめと次のステップ
今回は、Visual StudioとGitHub Actionsを使って、プッシュ時に自動ビルド＆テストを行う仕組みを作りました。
これにより、手動でのビルド忘れや、動作確認漏れを防ぎ、チーム開発でも品質を一定に保つことが可能になります。
今回のポイントを整理すると、次のとおりです。
- ワークフローファイルの基本構造（Workflow / Job / Step）
- ソースコードをプッシュすると自動的にビルド＆テストが実行される流れ
- 実行結果やログは GitHub の Actions タブから確認できる
次回は、ビルドしたアプリをAzureに自動デプロイする方法を解説します。
継続的デリバリー（CD）まで構築すれば、開発効率と品質がさらに向上します。
【おすすめ書籍】
ポチップ