Azure Pipelines構築ガイド|ビルド・デプロイを完全自動化するCI/CD手順
生徒
「Azure DevOpsを使って、ソースコードのビルドやデプロイを自動化したいのですが、どうすればいいですか?」
先生
「それならAzure Pipelines(アジュール パイプライン)を使うのが一番です。CI/CDという仕組みを作れば、作業効率が劇的に上がりますよ。」
生徒
「CI/CD(シーアイシーディー)ってよく聞きますけど、初心者でも設定できるものでしょうか?」
先生
「大丈夫です。手順を一つずつ確認しながら進めれば、必ず自動化の仕組みを構築できます。基本から一緒に学んでいきましょう!」
1. Azure Pipelinesとは?CI/CDの基本概念
Azure Pipelines(アジュール パイプライン)は、Microsoftが提供するクラウド型の自動化サービスです。ソフトウェア開発において、人間が手作業で行っていた「ビルド(プログラムの組み立て)」や「テスト」、「デプロイ(本番環境への配置)」を自動で行うためのツールです。
ここで重要なキーワードがCI/CD(シーアイシーディー)です。CIは「Continuous Integration(コンティニュアス インテグレーション:継続的インテグレーション)」の略で、コードを変更するたびに自動でビルドとテストを行う仕組みを指します。CDは「Continuous Delivery(コンティニュアス デリバリー:継続的デリバリー)」、または「Continuous Deployment(コンティニュアス デプロイメント:継続的デプロイ)」の略で、テストを通過したコードを自動で本番環境や検証環境に公開する仕組みを指します。
歴史的には、以前はこれらを「手動」で行うのが一般的でしたが、人為的なミスが発生しやすく、リリースまでに時間がかかるという課題がありました。Azure Pipelinesを導入することで、開発者はコードを書くことに集中できるようになり、高品質なアプリを素早くユーザーに届けられるようになります。
2. Azure DevOpsの準備とプロジェクト作成
Azure Pipelinesを利用するためには、まずAzure DevOps(アジュール デブオプス)のアカウントとプロジェクトが必要です。Azure DevOpsは、開発チームがプロジェクトを管理するための統合プラットフォームです。ソースコードを管理する「Azure Repos(アジュール レポス)」や、タスクを管理する「Azure Boards(アジュール ボーズ)」など、多くの機能が含まれています。
まずは公式サイトにアクセスし、組織(Organization)を作成しましょう。その中に「プロジェクト」を作成することで、Pipelineを構築する準備が整います。この際、プロジェクトを公開(Public)にするか非公開(Private)にするか選べますが、企業の開発であれば通常はPrivateを選択します。初心者の学習用であれば、まずは無料枠の範囲内で試してみるのが良いでしょう。
3. パイプラインの設定ファイル「azure-pipelines.yml」
Azure Pipelinesの最大の特徴は、自動化の手順をYAML(ヤムル)形式のファイルで記述することです。このファイル名は通常 azure-pipelines.yml となり、ソースコードと一緒にリポジトリに保存します。これにより、誰がいつ手順を変更したのかを履歴として残すことができます。
YAMLファイルには、「どのOS(エージェント)を使って実行するか」「どんなコマンドを実行するか」などを細かく記述していきます。例えば、.NETのアプリケーションをビルドする場合の非常にシンプルな構成例を見てみましょう。
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo "ビルドを開始します"
displayName: '開始メッセージの表示'
- task: DotNetCoreCLI@2
inputs:
command: 'build'
projects: '**/*.csproj'
arguments: '--configuration Release'
このコードでは、mainブランチにコードが追加されたときに、最新のUbuntu環境を使ってビルドを実行するように指示しています。taskという項目が、Azureが用意してくれている「便利な機能の塊」です。
4. ビルドパイプライン(CI)の構築手順
ビルドパイプラインの主な役割は、コードが壊れていないかを確認することです。複数の開発者が同時に作業している場合、誰かの変更が原因でエラーが発生することがあります。これを防ぐために、毎回自動でコンパイルを行い、エラーがないかチェックします。
構築の具体的な流れは以下の通りです:
- Azure DevOpsの左メニューから「Pipelines」を選択。
- 「Create Pipeline」ボタンをクリック。
- ソースコードの場所(Azure Repos, GitHubなど)を選択。
- テンプレート(ASP.NET Core, Node.jsなど)を選択するか、空のYAMLから作成。
ここで、C#の簡単なコードを使って、ビルドが成功したかどうかの判定を行うイメージをプログラムで表現してみましょう。実際にはAzure側が判定してくれますが、内部的な論理は以下のようになります。
using System;
class BuildChecker
{
static void Main()
{
bool isCodeErrorFree = true; // 本来はここでコードを解析
if (isCodeErrorFree)
{
Console.WriteLine("ビルド成功:アーティファクトを生成します。");
}
else
{
Console.WriteLine("ビルド失敗:修正が必要です。");
Environment.Exit(1); // エラー終了
}
}
}
ビルド成功:アーティファクトを生成します。
5. リリースパイプライン(CD)によるデプロイ自動化
ビルドが成功したら、次は生成物(アーティファクト)をサーバーへ送り届けます。これがデプロイです。Azure Pipelinesでは、「Release Pipelines」という機能を使って、視覚的にデプロイの流れを組むことができます。もちろん、YAMLで記述する「Multi-stage pipelines」という最新のやり方もあります。
デプロイ先は、Azure App Service(アジュール アップ サービス)や仮想マシン、あるいはAWS(エービーダブリューエス)やオンプレミスのサーバーなど、多岐にわたります。自動化のメリットは、深夜や早朝の作業を人間が担当しなくて済むことや、配布漏れなどのミスをゼロにできることです。
ここで、デプロイ時に実行されるスクリプトの例として、Linux環境でのファイル移動コマンドを見てみましょう。
mkdir -p /var/www/myapp
cp -r ./output/* /var/www/myapp/
ls /var/www/myapp
app.dll app.json web.config
6. 変数とシークレット情報の管理
パイプラインを運用する際、データベースの接続パスワードやAPIキーなどの機密情報をYAMLファイルに直接書くのは非常に危険です。セキュリティ上のリスクを避けるために、Azure Pipelinesには「Library(ライブラリ)」という機能があります。ここにVariable Groups(バリアブル グループ)を作成し、値を暗号化して保存します。
例えば、SQL Serverに接続する際の接続文字列を管理する場合、以下のような形式で設定されますが、実際の値は隠されます。
-- パイプラインがデータベースの準備として実行するクエリ例
CREATE TABLE DeploymentLogs (
LogID int IDENTITY(1,1) PRIMARY KEY,
Status nvarchar(50),
DeployDate datetime DEFAULT GETDATE()
);
INSERT INTO DeploymentLogs (Status) VALUES ('SUCCESS');
SELECT * FROM DeploymentLogs;
LogID | Status | DeployDate
------+---------+--------------------
1 | SUCCESS | 2026-03-31 12:00:00
7. セルフホステッドエージェントの活用
Azureが用意してくれる「Microsoft-hosted agents(マイクロソフト ホステッド エージェント)」は非常に便利ですが、社内ネットワークの中にあるサーバーにデプロイしたい場合や、特殊なソフトウェアが必要な場合は、自分で用意したサーバーをエージェントとして登録できます。これを「Self-hosted agent(セルフ ホステッド エージェント)」と呼びます。
自分のパソコンや社内サーバーにエージェントソフトをインストールし、Azure DevOpsと通信させることで、クラウドから安全に社内リソースを操作できるようになります。設定には多少の知識が必要ですが、自由度は格段に上がります。
8. パイプラインの監視とトラブルシューティング
自動化が完成しても、時にはエラーで止まることがあります。Azure Pipelinesの画面では、どのステップでエラーが起きたのか、ログを詳細に確認できます。よくある原因は、環境変数の設定ミスや、ライブラリのバージョン不一致などです。
エラーが発生した際は、ログの中から「Error」や「Failed」という単語を探しましょう。また、パイプラインの実行結果をメールやSlack、Microsoft Teamsに通知する設定をしておけば、不具合にいち早く気付くことができます。迅速な対応が、サービスの信頼性を高める鍵となります。
初心者が特につまずきやすいポイントとして、アクセス権限(Permissions)の設定があります。パイプラインがリポジトリを読み込む権限や、デプロイ先に書き込む権限が正しく割り当てられているか、必ず確認するようにしましょう。
まとめ
ここまで、Azure Pipelines(アジュール パイプライン)を活用したCI/CD(継続的インテグレーション/継続的デプロイ)の構築手順について詳しく解説してきました。クラウドネイティブな開発環境において、ビルドやテスト、デプロイといった一連の流れを自動化することは、開発効率を向上させるだけでなく、人為的なミスを削減し、ソフトウェアの品質を一定に保つために非常に重要です。
Azure DevOps(アジュール デブオプス)という強力なプラットフォームを利用することで、ソースコード管理からリリース管理までを一気通貫で行うことができます。特にYAML(ヤムル)形式で定義する「Pipeline as Code」の考え方は、設定変更の履歴をコードとして管理できるため、チーム開発において絶大な威力を発揮します。
Azure Pipelines導入のメリットと学習のポイント
初心者が最初に理解すべき点は、Azure Pipelinesが「トリガー(きっかけ)」「プール(実行環境)」「ステップ(手順)」の3つの要素で構成されていることです。リポジトリへのプッシュをトリガーにして、クラウド上のエージェントが動き出し、定義されたタスクを一つずつ実行していくという流れをイメージしてください。
また、実務においてはセキュリティ面への配慮も欠かせません。Variable Groups(バリアブル グループ)を利用して機密情報を保護し、適切なアクセス権限を割り当てることで、安全な自動化環境を構築できます。エラーが発生した際も、詳細なログを確認することで原因を特定し、迅速にトラブルシューティングを行う習慣をつけましょう。
実践的なC#による自動化スクリプト例
パイプラインの中で、特定の条件に基づいて処理を分岐させたり、独自のチェックを行いたい場合があります。例えば、デプロイ前に特定の構成ファイルが存在するかを確認するC#のコンソールアプリケーションをパイプライン内で実行するケースを想定してみましょう。
using System;
using System.IO;
namespace PipelineApp
{
class Program
{
static void Main(string[] args)
{
string configPath = "appsettings.json";
Console.WriteLine("構成ファイルのチェックを開始します...");
if (File.Exists(configPath))
{
Console.WriteLine("確認成功: " + configPath + " が見つかりました。");
// 正常終了
Environment.Exit(0);
}
else
{
Console.WriteLine("エラー: " + configPath + " が欠落しています。ビルドを中断します。");
// 異常終了(パイプラインが停止する)
Environment.Exit(1);
}
}
}
}
上記のプログラムをビルドし、パイプラインのタスクとして実行した際の出力結果は以下のようになります。
構成ファイルのチェックを開始します...
確認成功: appsettings.json が見つかりました。
データベース自動更新のSQL管理
CI/CDのフローには、アプリケーションのデプロイだけでなく、データベースのマイグレーション(テーブル定義の更新)を含めることも一般的です。Azure SQL Databaseなどに対して、デプロイ完了後にバージョン情報を記録するクエリを実行する例を確認しましょう。
実行前のシステム管理テーブルの状態は以下の通りです。
id | version | description | updated_at
---+---------+----------------------+--------------------
1 | v1.0.0 | Initial Release | 2026-01-01 10:00:00
2 | v1.1.0 | Added User Profile | 2026-02-15 15:30:00
新しいリリースを反映するために、以下のSQLを実行します。
-- 新しいリリース情報の挿入
INSERT INTO SystemVersions (version, description, updated_at)
VALUES ('v1.2.0', 'Azure Pipelines Integration', GETDATE());
-- 更新後の確認
SELECT id, version, description, updated_at
FROM SystemVersions
ORDER BY id DESC;
SQL実行後のテーブルの状態は、最新の履歴が追加された形になります。
id | version | description | updated_at
---+---------+-----------------------------+--------------------
3 | v1.2.0 | Azure Pipelines Integration | 2026-03-31 12:30:00
2 | v1.1.0 | Added User Profile | 2026-02-15 15:30:00
1 | v1.0.0 | Initial Release | 2026-01-01 10:00:00
レガシーシステムとの連携(COBOLの例)
最新のAzure環境であっても、基幹システムとの連携でCOBOL(コボル)などの言語が使われているプロジェクトも存在します。Azure Pipelinesでは、適切なコンパイラがインストールされたセルフホステッドエージェントを用意することで、COBOL資産のビルドを自動化することも可能です。
IDENTIFICATION DIVISION.
PROGRAM-ID. CHECK-STATUS.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-RESULT-MSG PIC X(30) VALUE "PIPELINE CHECK COMPLETED".
PROCEDURE DIVISION.
DISPLAY WS-RESULT-MSG.
STOP RUN.
Linuxエージェントでの環境確認
最後に、デプロイ先となるLinuxサーバーの状態を確認するためのコマンド操作です。Azure PipelinesからSSH経由、あるいはエージェント経由で実行されるコマンドの典型例を見てみましょう。
pwd
/home/azureuser/deploy/myapp
dotnet --version
8.0.200
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 30G 12G 18G 40% /
このように、Azure Pipelinesをマスターすることで、モダンな開発からレガシーな環境まで、幅広く自動化の恩恵を受けることができます。まずは小さなプロジェクトから試してみて、徐々に複雑なワークフローへとステップアップしていきましょう。自動化は一度構築してしまえば、将来の自分やチームを助ける最高の資産になります。
生徒
「先生、ありがとうございました!Azure Pipelinesの全体像がやっと見えてきました。YAMLファイルでビルドやデプロイの手順を全部書けるというのは、後から見返したときにも分かりやすくて便利ですね。」
先生
「その通りです。コードとして手順を残すことで、誰が設定を変えたかもすぐに分かりますし、プロジェクトを複製するときにも再利用しやすいんですよ。」
生徒
「記事の中で紹介されていたシークレット情報の管理も大切ですね。うっかりAPIキーをYAMLに書いてGitHubとかにプッシュしちゃったら大変なことになりますもんね。」
先生
「よく気づきましたね。セキュリティは自動化において最も慎重になるべき部分です。Variable Groups(バリアブル グループ)を使いこなして、安全なCI/CDパイプラインを目指しましょう。もしエラーが出ても、ログを読み解く力がつけば怖いものなしですよ。」
生徒
「はい!まずは自分のテスト環境で、簡単なC#アプリのビルドから試してみます。失敗を恐れずにチャレンジしてみます!」
先生
「素晴らしい意気込みですね。最初はエラーが出るのが当たり前ですから、一つずつ解決していけば大丈夫です。応援していますよ!」