CI/CD・DevSecOps・安全なリリース戦略 - 金融情報システム開発なら20年以上の実績があるテンファイブ株式会社

本章では、VB.NET業務システムを安全かつ継続的にリリースするための、 CI/CD、DevSecOps、ビルド自動化、テスト自動化、リリース戦略、ロールバック設計について学習します。

Chapter 18では、可観測性、監視、ログ、メトリクス、SREについて扱いました。しかし、どれだけ監視を整備しても、リリース作業そのものが手作業だらけであれば、人的ミス、手順漏れ、環境差異、切り戻し失敗などのリスクは残り続けます。

企業システムでは、リリース作業が以下のような状態になっていることがあります。

担当者のPCでビルドしている
手作業でexeやdllをコピーしている
本番環境だけ設定ファイルが違う
リリース手順書が古い
誰が何をリリースしたか追跡できない
障害時にすぐ戻せない
テスト実行が人任せになっている

この状態では、コードそのものが正しくても、リリース作業で障害を起こす可能性があります。

本章のゴールは、VB.NET業務システムにおいて、ビルド、テスト、静的解析、脆弱性チェック、成果物管理、デプロイ、リリース判定、ロールバックまでを体系的に設計し、安全に変更を本番環境へ届けられるDevOps基盤を構築できるようになることです。

1. CI/CDとは

CI/CDとは、アプリケーションのビルド、テスト、リリース、デプロイを自動化し、変更を安全かつ継続的に本番環境へ届けるための考え方です。

用語	意味	主な目的
CI	Continuous Integration	継続的インテグレーション
CD	Continuous Delivery / Deployment	継続的デリバリー / デプロイ

CIで行うこと

ソースコード取得
依存ライブラリ復元
ビルド
単体テスト
静的解析
成果物作成

CDで行うこと

成果物の保存
環境別設定の適用
検証環境へのデプロイ
受入テスト
本番デプロイ
ロールバック

CI/CDの目的は、単にリリースを速くすることではありません。変更を小さく、頻繁に、安全に届けることで、障害リスクを下げることが本質です。

2. 手作業リリースの問題

多くのレガシーVB.NETシステムでは、リリース作業が手順書ベースで行われています。

よくある手作業リリース

1. 開発者PCでReleaseビルドする
2. binフォルダからexeとdllを探す
3. zip化する
4. 共有フォルダへ置く
5. 本番サーバーへリモートログインする
6. 既存ファイルをバックアップする
7. 新しいファイルをコピーする
8. 設定ファイルを書き換える
9. IISまたはWindowsサービスを再起動する
10. 動作確認する

この方式では、担当者の経験や注意力に依存します。

手作業リリースのリスク

コピー漏れ
古いdllの混入
設定ファイルの上書き
環境差異
リリース対象間違い
バックアップ漏れ
切り戻し不能
作業証跡が残らない

手作業リリースを完全になくせない場合でも、ビルド、テスト、成果物作成、チェックリスト、リリース記録から段階的に自動化することが重要です。

3. CI/CDパイプラインの全体像

CI/CDパイプラインは、ソースコードの変更から本番リリースまでの一連の流れです。

基本フロー

Developer
   ↓
Git Push
   ↓
CI Trigger
   ↓
Restore Packages
   ↓
Build
   ↓
Unit Test
   ↓
Static Analysis
   ↓
Security Scan
   ↓
Package
   ↓
Artifact Store
   ↓
Deploy to Test
   ↓
Acceptance Test
   ↓
Deploy to Production

VB.NET業務システムでの対象

Windows Formsアプリ
WPFアプリ
ASP.NET / ASP.NET Core API
Windowsサービス
バッチアプリ
クラスライブラリ
DBマイグレーション
設定ファイル

CI/CDはWebアプリだけのものではありません。 VB.NETのデスクトップアプリ、バッチ、Windowsサービスでも、ビルドとテストの自動化は非常に有効です。

4. ソース管理戦略

CI/CDの前提は、すべての変更がソース管理されていることです。

管理すべきもの

VB.NETソースコード
プロジェクトファイル
ソリューションファイル
SQLスクリプト
マイグレーションファイル
設定テンプレート
ビルドスクリプト
CI/CD定義ファイル
テストコード

管理してはいけないもの

binフォルダ
objフォルダ
個人PC固有の設定
本番パスワード
API Key
一時ファイル
ログファイル

.gitignoreの例

bin/
obj/
.vs/
*.user
*.suo
*.log
TestResults/
packages/
.env

リポジトリを見れば、誰でも同じ成果物を再現できる状態にすることが重要です。

5. ブランチ戦略

チーム開発では、ブランチ戦略を決めておく必要があります。

代表的な戦略

戦略	特徴	向いているケース
Git Flow	develop、release、hotfixなどを使う	リリース周期が長い業務システム
GitHub Flow	mainと短命ブランチ中心	頻繁にリリースするWebサービス
Trunk-Based Development	mainへ小さく統合する	CI/CDが整備されたチーム

業務システムでよくある構成

main
  本番リリース済みコード

develop
  次回リリース候補

feature/*
  機能開発

release/*
  リリース準備

hotfix/*
  本番障害対応

重要なのは、ブランチの数ではなく、どのブランチがどの環境へデプロイされるのかを明確にすることです。

避けたい状態

どのブランチが本番相当か分からない
長期間マージされないfeatureブランチがある
本番修正がdevelopへ反映されていない
リリース直前に大量マージする
手元の未コミット差分からリリースする

6. ビルド自動化

CIの最初の基本は、開発者PCではなくCIサーバー上でビルドできることです。

ビルド自動化の目的

誰が実行しても同じ成果物を作る
ビルド漏れを防ぐ
依存関係の不整合を検知する
リリース可能な成果物を保存する
手元PC依存をなくす

MSBuildの例

msbuild MyApplication.sln /p:Configuration=Release /p:Platform="Any CPU"

dotnet CLIの例

dotnet restore

dotnet build MyApplication.sln --configuration Release

dotnet test MyApplication.Tests.vbproj --configuration Release

.NET Framework系の古いVB.NETプロジェクトではMSBuildを使うことが多く、 .NET Core / .NET 5以降のプロジェクトではdotnet CLIを利用できます。

ビルドで検出したい問題

コンパイルエラー
参照dll不足
NuGet復元失敗
Option Strict違反
警告の増加
テスト失敗

7. テスト自動化

CI/CDでは、リリース前に自動テストを実行することが重要です。

自動化すべきテスト

単体テスト
結合テスト
APIテスト
DBマイグレーションテスト
回帰テスト
重要業務シナリオテスト

VB.NETの単体テスト例

<TestClass>
Public Class OrderCalculatorTests

    <TestMethod>
    Public Sub CalculateTotal_WithTax_ReturnsExpectedAmount()

        Dim calculator As New OrderCalculator()

        Dim result =
            calculator.CalculateTotal(1000D, 0.1D)

        Assert.AreEqual(1100D, result)

    End Sub

End Class

CIでテストを実行する例

dotnet test MyApplication.Tests.vbproj --configuration Release

最初からすべてを自動テスト化する必要はありません。金額計算、税計算、ステータス遷移、権限判定など、壊れると影響が大きい処理から優先的に自動化します。

8. 品質ゲート

品質ゲートとは、一定の品質条件を満たさない変更を次の工程へ進めない仕組みです。

品質ゲートの例

ビルドが成功している
単体テストがすべて成功している
重大な静的解析エラーがない
高リスク脆弱性がない
コードレビューが完了している
DBマイグレーションが成功している

悪い例

テストが落ちているが、急ぎなので本番反映する。

このような例外対応を繰り返すと、CI/CDは形だけになります。本当に緊急の場合を除き、品質ゲートを破らない文化が重要です。

Pull Requestで確認すること

CIが成功しているか
テストが追加されているか
既存仕様を壊していないか
ログや監視が必要な変更か
DB変更があるか
セキュリティ影響があるか

9. 静的解析

静的解析は、コードを実行せずに品質や潜在的な問題を検出する仕組みです。

検出できる問題

未使用変数
到達不能コード
複雑すぎるメソッド
例外握りつぶし
SQLインジェクションリスク
Null参照リスク
命名規則違反
重複コード

例外握りつぶしの悪い例

Try
    ExecuteImportantProcess()
Catch ex As Exception
End Try

このようなコードは、障害を隠してしまいます。静的解析やコードレビューで検出すべき対象です。

改善例

Try
    ExecuteImportantProcess()

Catch ex As Exception

    Logger.Error(
        "重要処理で例外が発生しました。",
        ex)

    Throw

End Try

静的解析は、レビュー担当者の負担を減らし、機械的に検出できる問題を自動でチェックするために有効です。

10. DevSecOpsとは

DevSecOpsとは、開発と運用の流れの中にセキュリティを組み込み、リリース直前ではなく開発初期から継続的にセキュリティを確認する考え方です。

従来のように「開発が終わってからセキュリティ診断する」だけでは、問題が見つかったときの修正コストが大きくなります。

DevSecOpsで行うこと

依存ライブラリの脆弱性チェック
ソースコードのセキュリティ解析
Secret漏えい検知
コンテナイメージスキャン
権限設定チェック
IaC設定チェック
監査ログ確認

セキュリティは専門部署だけの作業ではなく、開発パイプラインの一部として継続的に確認します。

11. Secret管理

CI/CDで非常に重要なのがSecret管理です。

Secretの例

DB接続文字列
API Key
Client Secret
署名鍵
証明書パスワード
本番環境の認証情報

やってはいけない例

Private Const ConnectionString As String =
    "Server=prod-db;Database=Main;User ID=admin;Password=P@ssw0rd"

Secretをソースコードへ直接書いてはいけません。また、CI/CD定義ファイルに平文で書くことも避けます。

望ましい管理方法

CI/CDツールのSecret機能を使う
環境変数として渡す
Key VaultやSecret Managerを利用する
本番Secretへアクセスできる権限を限定する
Secretのローテーション手順を用意する

環境変数から取得する例

Dim connectionString As String =
    Environment.GetEnvironmentVariable(
        "APP_CONNECTION_STRING")

設定値とSecretをコードから分離することで、環境ごとの差し替えやSecret更新を安全に行いやすくなります。

12. 依存ライブラリ管理

VB.NETシステムでは、NuGetパッケージや外部dllを利用します。これらの依存関係もCI/CDで管理する必要があります。

管理すべき項目

ライブラリ名
バージョン
ライセンス
脆弱性情報
サポート状況
更新履歴

リスク

古いライブラリに脆弱性がある
サポート終了ライブラリを使い続ける
ライセンス違反になる
バージョン更新で互換性が壊れる
開発環境とCI環境で参照dllが違う

NuGet復元

nuget restore MyApplication.sln

外部dllを手動でプロジェクトへコピーする方式は、環境差異の原因になりやすいです。可能な限りNuGetや内部パッケージ管理へ移行します。

13. 成果物管理

ビルドした成果物は、どのソースコードから作られたものか追跡できる必要があります。

成果物に含める情報

アプリケーション名
バージョン番号
ビルド番号
コミットID
ビルド日時
環境

成果物名の例

OrderSystem_1.8.0_build20261007_8f3a91c.zip

バージョン情報クラス例

Public Class BuildInfo

    Public Shared ReadOnly Property Version As String
        Get
            Return "1.8.0"
        End Get
    End Property

    Public Shared ReadOnly Property CommitId As String
        Get
            Return "8f3a91c"
        End Get
    End Property

End Class

障害発生時に、本番環境でどのバージョンが動いているのか分からない状態は危険です。画面、API、ログ、監視からバージョンを確認できるようにします。

14. 環境管理

CI/CDでは、開発、検証、本番など複数環境を扱います。

代表的な環境

環境	用途
Development	開発者の作業環境
Test	結合テスト環境
Staging	本番相当の最終確認環境
Production	本番環境

環境差異で起きる問題

検証環境では成功するが本番では失敗する
DBスキーマが違う
設定値が違う
外部API接続先が違う
権限が違う
ファイルパスが違う

環境別設定の例

appsettings.Development.json
appsettings.Test.json
appsettings.Staging.json
appsettings.Production.json

.NET Framework系のapp.configやweb.configでも、設定変換やテンプレート化を利用して環境差異を管理できます。

15. DBマイグレーション

業務システムでは、アプリケーションだけでなくDB変更もリリース対象です。

DB変更の例

テーブル追加
カラム追加
インデックス追加
制約追加
マスタデータ投入
ストアドプロシージャ変更
ビュー変更

危険なDBリリース

本番DBへ手作業でSQLを実行する。
実行履歴は残していない。
戻しSQLも用意していない。

DB変更はアプリケーション以上に切り戻しが難しい場合があります。そのため、SQLスクリプトの管理、適用順序、事前検証、バックアップ、戻し方を明確にします。

マイグレーション管理テーブル例

SchemaVersions

Version
ScriptName
AppliedAt
AppliedBy
Checksum

SQLスクリプト命名例

V001_CreateOrdersTable.sql
V002_AddOrderStatusColumn.sql
V003_CreateIndex_Orders_CustomerId.sql
V004_InsertInitialOrderStatusMaster.sql

どのSQLがどの環境に適用済みかを管理することで、環境差異や実行漏れを防ぎやすくなります。

16. DB変更と後方互換性

安全なリリースでは、アプリケーションとDBを同時に完全一致させるのではなく、段階的に互換性を保ちながら変更する考え方が重要です。

危険な変更

既存カラムを即削除する
カラム名を即変更する
NOT NULLカラムを初期値なしで追加する
既存APIのレスポンス項目を削除する

安全な変更手順例

1. 新カラムをNULL許容で追加する
2. アプリケーションを新旧両方に対応させる
3. 既存データを移行する
4. 新カラムを利用するアプリへ切り替える
5. 十分な期間後に旧カラムを削除する

DB変更は、アプリケーションのリリースと密接に関係します。 Blue-Green DeploymentやRolling Deploymentを行う場合は、新旧バージョンが一時的に同じDBへアクセスする可能性を考慮します。

17. デプロイ方式

デプロイ方式には複数の種類があります。業務要件、システム構成、停止許容時間に応じて選択します。

方式	特徴	向いているケース
In-Place	既存環境へ上書き	小規模、停止許容あり
Blue-Green	新旧環境を切り替える	切り戻しを速くしたい
Rolling	複数台を順番に更新	複数サーバー構成
Canary	一部ユーザーへ先行公開	リスクを小さく検証したい

古いVB.NETデスクトップアプリではClickOnceや配布ツールを利用する場合もあります。 Web APIやWindowsサービスでは、Blue-GreenやRollingの考え方を適用しやすいです。

18. Blue-Green Deployment

Blue-Green Deploymentは、本番相当の環境を2つ用意し、片方を稼働中、もう片方を新バージョンとして準備する方式です。

現在稼働中

User
 ↓
Blue Environment
 ↓
Database

新バージョン準備

Green Environment
 ↓
Database

Green環境で動作確認が完了したら、ルーティングをBlueからGreenへ切り替えます。

メリット

切り替えが速い
問題発生時に戻しやすい
本番相当環境で事前確認できる

注意点

環境を2つ維持するコストがある
DB変更の互換性が必要
ファイル保存先やセッション管理に注意する
切り替え後の監視が重要

Blue-Greenはアプリケーションの切り戻しには強いですが、 DB破壊的変更を含む場合は簡単には戻せません。 DB変更設計とセットで考える必要があります。

19. Canary Release

Canary Releaseは、新バージョンを一部のユーザーや一部のリクエストだけに公開し、問題がないことを確認してから段階的に拡大する方式です。

Version 1
  95%

Version 2
  5%

段階例

Step 1: 1%に公開

Step 2: 5%に拡大

Step 3: 25%に拡大

Step 4: 50%に拡大

Step 5: 100%に切り替え

監視する指標

エラー率
応答時間
注文成功率
例外件数
外部API失敗率
ユーザー問い合わせ件数

Canary Releaseでは、段階拡大の判断基準を事前に決めておきます。感覚ではなく、メトリクスに基づいて拡大または停止を判断します。

20. Feature Flag

Feature Flagは、コードをリリースしておきながら、機能の有効・無効を設定で切り替える仕組みです。

用途

新機能を一部ユーザーだけに公開する
問題発生時に機能だけ停止する
開発中機能をmainブランチへ統合しやすくする
A/Bテストを行う

簡易実装例

Public Class FeatureFlags

    Public Property NewOrderScreenEnabled As Boolean

    Public Property AsyncInvoiceEnabled As Boolean

End Class

If _featureFlags.NewOrderScreenEnabled Then
    ShowNewOrderScreen()
Else
    ShowLegacyOrderScreen()
End If

Feature Flagの注意点

Flagが増えすぎると複雑になる
使い終わったFlagを削除する
Flagの組み合わせテストが必要になる
本番設定ミスが障害につながる

Feature Flagは便利ですが、永続的な分岐を増やす道具ではありません。役目を終えたFlagは削除する運用が必要です。

21. ロールバック戦略

リリースでは、問題が発生したときにどう戻すかを事前に決めておく必要があります。

ロールバック対象

アプリケーション
設定ファイル
DBスキーマ
マスタデータ
バッチ
外部連携設定

アプリケーションのロールバック

現在バージョン：1.8.0

問題発生

前バージョン：1.7.3へ戻す

アプリケーションだけなら、前の成果物へ戻すことで復旧できる場合があります。

DB変更がある場合

DBスキーマ変更やデータ移行を伴う場合、単純なロールバックは難しくなります。

対応方針

破壊的変更を避ける
前バージョンも動くDB構造にする
戻しSQLを用意する
データバックアップを取得する
ロールフォワードも検討する

リリース計画には、成功手順だけでなく、失敗時の戻し手順も含める必要があります。

22. ロールフォワード

ロールフォワードとは、前のバージョンへ戻すのではなく、修正版を追加リリースして復旧する方法です。

ロールフォワードが向いているケース

DB変更を戻すのが危険
データ移行が既に進んでいる
問題箇所が限定的
短時間で修正パッチを出せる

判断例

アプリケーションだけの不具合
  → ロールバックしやすい

DBデータ変換後の不具合
  → ロールフォワードを検討

一部機能だけの不具合
  → Feature Flagで無効化

ロールバックとロールフォワードのどちらを選ぶかは、事前に判断基準を決めておくと障害時に迷いにくくなります。

23. Windowsサービスのリリース

VB.NETで作られたWindowsサービスや常駐バッチは、リリース時に停止・更新・起動が必要です。

基本手順

1. サービス停止
2. プロセス停止確認
3. 既存ファイル退避
4. 新ファイル配置
5. 設定確認
6. サービス起動
7. ログ確認
8. ヘルスチェック

PowerShell例

Stop-Service -Name "OrderWorker"

Copy-Item ".\publish\*" "C:\Apps\OrderWorker" -Recurse -Force

Start-Service -Name "OrderWorker"

Get-Service -Name "OrderWorker"

注意点

処理中ジョブをどう扱うか
二重起動を防ぐ
停止に時間がかかる場合を考慮する
未処理Queueを失わないようにする
起動後にConsumerが正常に処理しているか確認する

Windowsサービスのリリースでは、単にプロセスを再起動するだけでなく、実行中処理やQueue状態まで含めて設計します。

24. デスクトップアプリの配布

VB.NETのWindows FormsやWPFでは、クライアントPCへの配布が課題になります。

配布方法の例

手動コピー
共有フォルダ配布
ClickOnce
MSIインストーラー
社内配布ツール
VDI / リモートアプリ

配布で考慮すること

全端末が同じバージョンか
更新失敗時に起動できるか
古いバージョンの利用を防げるか
必要な.NET Runtimeが入っているか
ローカル設定をどう保持するか
ロールバックできるか

バージョンチェック例

Public Function IsSupportedVersion(
    currentVersion As Version,
    minimumVersion As Version) As Boolean

    Return currentVersion >= minimumVersion

End Function

業務上、古いクライアントがDBやAPIへ接続し続けると問題になる場合があります。最低利用可能バージョンをサーバー側で管理する設計も有効です。

25. リリースノート

リリースノートは、今回のリリース内容を関係者へ共有するための文書です。

含める内容

リリース日
バージョン番号
新機能
修正内容
既知の問題
DB変更
設定変更
影響範囲
確認観点
ロールバック方針

リリースノート例

Version:
  1.8.0

Release Date:
  2026/10/07

Changes:
  - 注文検索画面の性能改善
  - 請求バッチのリトライ処理追加
  - 在庫API連携ログにCorrelation IDを追加

DB Changes:
  - OrdersテーブルにIndexを追加

Risk:
  - 注文検索処理に影響

Rollback:
  - アプリケーションは1.7.3へ戻し可能
  - DB Index追加は残置可能

リリースノートがあると、運用、QA、業務担当者、問い合わせ対応者が変更内容を把握しやすくなります。

26. リリース判定会

大規模な業務システムでは、本番リリース前にリリース判定を行うことがあります。

確認項目

対象機能の開発が完了しているか
テストが完了しているか
重大障害が残っていないか
性能確認が完了しているか
セキュリティ確認が完了しているか
DB変更が確認済みか
リリース手順が整備されているか
ロールバック手順があるか
運用担当者へ共有済みか

判定結果

判定	意味
Go	リリース実施
Conditional Go	条件付きで実施
No Go	リリース延期

リリース判定は、形式的な会議にするのではなく、リスクを共有し、実施可否を判断する場として機能させる必要があります。

27. リリース後監視

リリースは、デプロイが終わったら完了ではありません。リリース後にシステムが正常に動作していることを監視する必要があります。

監視項目

エラー率
応答時間
CPU / メモリ
DB負荷
Queue滞留
バッチ実行状況
ログの異常増加
問い合わせ件数

リリース直後の確認例

リリース後15分：
  Error Rate確認

リリース後30分：
  API Latency確認

リリース後1時間：
  Queue滞留確認

翌営業日：
  業務影響・問い合わせ確認

Canary ReleaseやBlue-Green Deploymentでも、切り替え後の監視が重要です。問題が見つかった場合は、事前に決めた基準に従ってロールバックまたはロールフォワードを判断します。

28. CI/CD定義の例

以下は、VB.NETプロジェクトに対するCI/CD定義の概念例です。実際の記法は利用するCI/CDツールによって異なります。

pipeline:

  trigger:
    branches:
      - develop
      - main

  stages:

    - restore:
        command: dotnet restore

    - build:
        command: dotnet build --configuration Release

    - test:
        command: dotnet test --configuration Release

    - static_analysis:
        command: run-code-analysis

    - security_scan:
        command: scan-dependencies

    - package:
        command: create-artifact

    - deploy_test:
        condition: branch == develop

    - deploy_production:
        condition: branch == main
        approval: required

重要なのは、ツールの種類ではなく、パイプライン上で何を検証し、どの条件を満たしたら次へ進めるかを明確にすることです。

29. 実務でありがちな失敗

開発者PCでビルドしたものを本番へ出す

開発者PCには、CI環境や本番環境に存在しないdll、設定、環境変数がある可能性があります。成果物はCI環境で作成します。

テストが落ちているのにリリースする

テスト失敗を無視する運用が続くと、CIの信頼性が失われます。失敗したテストは、修正するか、不要なら削除・見直しを行います。

DB変更を手作業で実行する

手作業SQLは実行漏れ、順序ミス、環境差異の原因になります。 SQLスクリプトを管理し、適用履歴を残します。

Secretをリポジトリへ入れる

一度コミットされたSecretは履歴に残ります。検知した場合は削除だけでなく、Secretのローテーションも必要です。

ロールバック手順がない

問題が起きてから戻し方を考えると、復旧が遅れます。リリース前に戻し方を確認します。

Feature Flagを放置する

使い終わったFlagを残すと、コードの分岐が増え続け、テストが複雑になります。期限を決めて削除します。

リリース後監視をしない

デプロイが成功しても、業務処理が正常とは限りません。リリース後はエラー率、応答時間、Queue、DB、業務指標を確認します。

30. 演習課題

演習1：CIパイプラインを設計する

VB.NETの業務アプリについて、restore、build、test、static analysis、packageまでのCIパイプラインを設計してください。

演習2：品質ゲートを定義する

Pull Requestをmainへマージするために必要な条件を定義してください。ビルド、テスト、レビュー、脆弱性、DB変更の観点を含めてください。

演習3：Secret管理を改善する

ソースコードにDB接続文字列が直接書かれている既存システムを想定し、環境変数またはSecret管理サービスへ移行する手順を作成してください。

演習4：DBマイグレーションを設計する

Ordersテーブルへ新しいStatus列を追加する場合の、安全なDB変更手順を設計してください。既存アプリとの後方互換性も考慮してください。

演習5：Blue-Green Deploymentを設計する

ASP.NET APIで構築された受注システムについて、 Blue-Green Deploymentによるリリース手順と切り戻し手順を設計してください。

演習6：Feature Flagを設計する

新しい注文登録画面を一部ユーザーだけに公開するためのFeature Flagを設計してください。有効化条件、無効化手順、削除タイミングも含めてください。

演習7：Windowsサービスのリリース手順を作る

Queueを処理するWindowsサービスについて、安全な停止、成果物配置、起動、ヘルスチェック、失敗時の戻し手順を作成してください。

演習8：リリースノートを作成する

注文検索高速化、請求バッチ修正、DBインデックス追加を含むリリースについて、業務担当者と運用担当者向けのリリースノートを作成してください。

演習9：リリース後監視を設計する

本番リリース後1時間で確認すべきメトリクス、ログ、業務指標を整理してください。問題が発生した場合の判断基準も定義してください。

31. まとめ

本章では、VB.NET業務システムにおけるCI/CD、DevSecOps、安全なリリース戦略について学習しました。

CI/CDの目的は、単にリリースを速くすることではありません。ビルド、テスト、静的解析、セキュリティチェック、成果物管理、デプロイ、ロールバックを標準化し、人的ミスを減らしながら安全に変更を本番環境へ届けることです。

CIでは、開発者PCではなくCI環境でビルドし、単体テストや静的解析を自動実行します。これにより、環境差異やビルド漏れを早い段階で検知できます。

CDでは、成果物を管理し、検証環境、本番環境へ一貫した手順でデプロイします。手作業コピーや担当者依存のリリースから脱却し、誰が実行しても同じ結果になる仕組みを目指します。

DevSecOpsでは、セキュリティをリリース直前の確認事項ではなく、開発パイプラインの一部として扱います。 Secret漏えい、依存ライブラリの脆弱性、権限設定、静的解析などを継続的に確認することが重要です。

DB変更は、アプリケーションリリース以上に慎重な設計が必要です。 SQLスクリプトを管理し、適用履歴を記録し、後方互換性を意識して段階的に変更します。破壊的変更を避けることが、安全なリリースの鍵になります。

リリース方式には、In-Place、Blue-Green、Rolling、Canaryなどがあります。システム構成、停止許容時間、利用者影響、DB変更の有無に応じて適切な方式を選択します。

Feature Flagを利用すると、コードのリリースと機能公開を分離できます。問題発生時には機能だけを無効化できるため、リスクを下げられます。ただし、不要になったFlagを放置すると複雑性が増すため、削除運用も必要です。

ロールバック戦略では、アプリケーション、DB、設定、外部連携を含めて戻し方を事前に決めます。 DB変更を伴う場合は単純なロールバックが難しいため、ロールフォワードやFeature Flagによる停止も検討します。

また、リリースはデプロイ完了で終わりではありません。リリース後のエラー率、応答時間、Queue滞留、DB負荷、業務指標を監視し、問題があれば早期に検知して対応できる体制が必要です。

本章のゴールは、VB.NET業務システムを「手作業で壊さないようにリリースする状態」から、「自動化されたパイプラインで検証し、安全に継続的にリリースできる状態」へ引き上げることです。 CI/CDとDevSecOpsを導入することで、開発速度と安定性を両立し、長期運用に耐えるエンタープライズシステムを実現できます。