LESSON 30分

ストーリー

田中VPoE
設計原則を理解したところで、具体的なパイプラインの中身を標準化していこう。ビルド、テスト、デプロイ — この3つのステージの標準を定義する
あなた
チームによって技術スタックが違いますが、標準化できるんですか?TypeScriptのチームもあればPythonのチームもあります
田中VPoE
いいポイントだ。言語やフレームワークに依存する部分は抽象化し、プロセスとしての標準を定義する。何を使うかはチームの自由、どういうプロセスを踏むかは組織の標準、という考え方だ

ビルドステージの標準化

標準ビルドプロセス

すべてのチームが従うべきビルドプロセスの標準を定義します。

標準ビルドフロー:

1. 依存関係の解決(キャッシュ活用)
2. 静的解析(Lintチェック)
3. コンパイル / ビルド
4. ユニットテスト実行
5. アーティファクト生成
6. アーティファクトの署名

ビルド品質ゲート

ビルドが「成功」と見なされるための最低基準を組織で統一します。

ゲート基準強制/推奨
Lintエラー0件強制
コンパイルエラー0件強制
ユニットテスト全テストパス強制
テストカバレッジ新規コード80%以上推奨(段階的に強制化)
ビルド時間10分以内推奨

マルチ言語対応

# Reusable Workflow: 言語非依存のビルドステージ
name: Standard Build
on:
  workflow_call:
    inputs:
      language:
        type: string
        required: true
      build-command:
        type: string
        default: ""

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Runtime
        uses: org/setup-runtime@v1
        with:
          language: ${{ inputs.language }}

      - name: Install Dependencies
        uses: org/install-deps@v1
        with:
          language: ${{ inputs.language }}
          cache: true

      - name: Lint
        uses: org/lint@v1
        with:
          language: ${{ inputs.language }}

      - name: Build
        run: ${{ inputs.build-command || 'make build' }}

      - name: Unit Test
        uses: org/unit-test@v1
        with:
          language: ${{ inputs.language }}
          coverage-threshold: 80

テストステージの標準化

テストピラミッドの組織標準

テストの種類と実行タイミングを組織全体で標準化します。

                    /\
                   /  \
                  / E2E \        ← リリース前のみ
                 /--------\
                / 統合テスト \     ← PR マージ前
               /--------------\
              /  ユニットテスト  \  ← 全コミット
             /------------------\
テスト種別実行タイミング実行時間目標必須/任意
ユニットテスト全コミット< 5分必須
統合テストPRマージ前< 15分必須
E2Eテストリリース前< 30分必須(クリティカルパスのみ)
パフォーマンステストリリース前< 60分推奨
セキュリティテストPRマージ前< 10分必須

テスト失敗時のポリシー

シナリオポリシー
ユニットテスト失敗PRマージをブロック
統合テスト失敗PRマージをブロック
E2Eテスト失敗リリースをブロック(手動オーバーライド可)
Flaky テスト検出自動的にリトライ(3回まで)、チームに通知

デプロイステージの標準化

デプロイ戦略の標準

組織で使用するデプロイ戦略を標準化します。

戦略用途リスク推奨環境
Rolling Update標準的なデプロイステージング
Blue/Greenゼロダウンタイムデプロイプロダクション
Canary段階的リリース最低プロダクション(重要サービス)
Feature Flag機能の段階的公開最低全環境

標準デプロイフロー

PR Merge → Build → Test → Security Scan

                        Staging Deploy

                        Staging Test

                   Production Approval(手動 or 自動)

                        Canary Deploy(5%)

                   メトリクス確認(エラー率、レイテンシ)

                        段階的ロールアウト

                        Full Deploy(100%)

ロールバック基準

指標閾値アクション
エラー率前バージョンの2倍以上自動ロールバック
レイテンシ(p99)前バージョンの1.5倍以上アラート発報、手動判断
CPU/メモリ使用率90%以上アラート発報、手動判断

まとめ

ポイント内容
ビルド標準言語非依存のプロセス標準、Reusable Workflowで共通化
テスト標準テストピラミッドに基づく実行タイミングと品質ゲート
デプロイ標準漸進的デプロイ戦略と自動ロールバック基準

チェックリスト

  • ビルド品質ゲートの基準を理解した
  • テストピラミッドの組織標準を理解した
  • デプロイ戦略の標準と自動ロールバック基準を理解した

次のステップへ

次は「アーティファクト管理とバージョニング」です。ビルドされたアーティファクトをどう管理し、どうバージョンを振るかを学びましょう。


推定読了時間: 30分