SAP HANA Development
SAP HANA開発のCI/CD基礎：MTAビルドから安全なデプロイまで
SAP HANA on-premiseの開発でCI/CDパイプラインを設計するために、Git、MTAビルド、テスト、HDIコンテナへのデプロイ、SAP HANA cockpitでの確認方法を実務向けに整理します。
SAP HANAの開発でCI/CDを導入すると、SQLScript、Calculation View、CDS成果物、アプリケーションコードを、決められた手順で検証して環境へ届けられます。重要なのは、単にビルドを自動化することではなく、成果物の境界、テストの責任範囲、デプロイ先の権限、失敗時の確認方法を先に定義することです。
この記事では、SAP HANA on-premise環境の開発チームが、Gitリポジトリを起点にMTAプロジェクトをビルドし、テストを実行し、HDIコンテナや関連サービスへデプロイする基本構成を扱います。開発対象の整理にはSAP HANA開発の全体像も役立ちます。
CI/CDで分ける責任範囲
CI/CDパイプラインは、次の4つの段階に分けると運用しやすくなります。
- 変更管理：開発者がブランチへ変更を登録し、レビュー可能な状態にする
- 検証：構文、依存関係、ビルド、単体テスト、静的チェックを実行する
- パッケージ化：MTAアーカイブなど、環境へ渡せる成果物を作成する
- デプロイと確認：対象環境へ配布し、コンテナ、テーブル、サービス、アプリケーションの状態を確認する
この分割により、ビルドは成功したがデプロイに失敗したケースや、デプロイは成功したが権限設定に問題があるケースを切り分けやすくなります。各段階のログは、パイプラインの実行ID、コミットID、対象環境、実行者と結び付けて保存します。
リポジトリとブランチの設計
リポジトリには、データベース成果物、アプリケーションコード、設定ファイル、テストコードを、責任範囲が分かる構造で格納します。HDIベースの開発では、db、srv、appなどのモジュールをMTAプロジェクト内で管理する構成が一般的です。
ブランチ運用では、短命の作業ブランチからレビューを経て統合ブランチへマージする流れが扱いやすいでしょう。統合ブランチへのマージをCIの起点にし、共有環境へのデプロイは承認済みのタグやリリースブランチから実行します。
コミットには、変更したDBオブジェクト、互換性への影響、必要なデータ移行、ロール変更の有無を記録します。テーブル定義やビュー定義を変更する場合は、既存データを保持したまま適用できるかをパイプラインの検証項目に含めます。
MTAプロジェクトをビルドする
MTAプロジェクトでは、mta.yamlがモジュール、依存関係、リソース、デプロイ時の構成を表します。最初に、DBモジュールとサービスモジュールの依存関係を確認し、ビルド環境に必要なNode.js、Java、MTA Build Toolなどのバージョンを固定します。
基本的な流れは次のとおりです。
- リポジトリをクリーンなワークスペースへ取得する
- 依存パッケージをロックファイルに基づいてインストールする
- リンターとユニットテストを実行する
mbt buildでMTAアーカイブを作成する- アーカイブ名、コミットID、ビルドログを保管する
ビルドサーバーには、開発者のローカル環境にだけ存在するファイルや認証情報を持ち込まないでください。生成物ディレクトリ、ローカル設定、秘密鍵、接続パスワードはリポジトリから分離し、パイプラインの安全な認証情報ストアで管理します。
MTA構成を詳しく確認したい場合は、SAP HANA HDIコンテナの基礎で、コンテナ、デプロイヤー、サービスバインディングの関係を整理できます。
SQLScriptとデータベース成果物を検証する
SQLScriptプロシージャやテーブル関数を含む場合、CIではビルドだけでなく、入力値、NULL、空データ、重複データ、トランザクション境界を検証します。処理結果だけでなく、エラーが期待どおりに返ることもテスト対象にします。
Calculation Viewでは、入力パラメータ、フィルタ、結合条件、集計粒度を確認します。意図しない行の増加は、結合後のレコード件数や主要なキーの一意性を検査すると見つけやすくなります。Calculation Viewの構成を見直すときは、SAP HANA Calculation Viewの実装ガイドを参照できます。
テスト用データは、個人情報や本番の秘密情報を含まない固定データセットにします。テストがデータベースの状態に依存する場合は、セットアップ、実行、クリーンアップを明示し、同じコミットで繰り返し実行できるようにします。
SQLScriptのテストでは、次の観点をパイプラインの必須項目にできます。
- 正常系の代表的な入力
- 境界値とNULL
- 権限不足時の動作
- 期待する件数と集計値
- 実行時間の基準値
- エラー後のロールバック状態
SQLScriptの設計やプロシージャの責務を整理する場合は、SAP HANA SQLScriptプロシージャの実装も関連します。
デプロイ先を段階化する
環境は、開発、統合テスト、受入テスト、本番のように役割ごとに分けます。各環境で異なる接続先や資格情報は、MTAアーカイブに直接埋め込まず、デプロイ時のパラメータや環境側のサービス構成で解決します。
最初の自動デプロイ先は、開発者が共有して使う環境ではなく、再作成しやすい統合環境にすると、失敗したデプロイの再実行を安全に検証できます。受入環境と本番環境では、ビルドし直したアーカイブではなく、検証済みの同一アーカイブを昇格させます。これにより、環境ごとに異なるビルド結果が発生するリスクを抑えられます。
デプロイ前には、次の確認を行います。
- 対象のシステムデータベースまたはテナントデータベースが稼働している
- デプロイ用ユーザーに必要な権限がある
- サービスインスタンスとサービスキーが存在する
- 破壊的なDB変更に対するバックアップと復旧手順がある
- 実行中のジョブやデータロードとの競合がない
SAP HANA cockpitでは、システムの状態、アラート、サービス、SQL実行状況を確認できます。SAP HANA database explorerでは、対象データベースへの接続、カタログオブジェクト、SQL実行結果を確認し、デプロイ後の検証に利用できます。
権限と秘密情報を分離する
CI/CD用の技術ユーザーには、パイプラインが実行する操作に必要な最小限の権限だけを付与します。開発用、統合テスト用、本番用のユーザーを分け、同じパスワードや同じキーを複数環境で再利用しない構成にします。
秘密情報は、ソースコード、mta.yaml、ビルドログ、アーカイブ名、通知本文へ出力しません。接続情報をログへ表示する処理がある場合はマスキングし、失敗時の診断には接続先の識別子やデプロイ操作の結果だけを残します。
HDIコンテナを使う場合は、オブジェクト所有者、アプリケーション用ユーザー、外部アクセス用ユーザーの役割を分けます。分析用の参照権限と、スキーマ変更やデプロイを行う権限を同じユーザーへ集約しないことが、誤操作の範囲を抑えるポイントです。
失敗したパイプラインを切り分ける
失敗箇所を、ソース取得、依存パッケージ、テスト、MTAビルド、認証、サービスバインディング、DBデプロイ、アプリケーション起動に分けます。最初に確認するのは最後のエラーだけではなく、最初に異常が発生したステップです。
ビルド失敗では、ロックファイル、ツールのバージョン、生成物の差分、MTAモジュールの依存関係を確認します。デプロイ失敗では、対象スペース、ターゲットデータベース、サービスインスタンス、ユーザー権限、デプロイログを確認します。
DBオブジェクトの作成失敗では、依存するテーブルやビューの順序、既存オブジェクトとの衝突、予約語、権限を確認します。アプリケーション起動失敗では、サービスバインディング、環境変数、ポート、接続ユーザー、アプリケーションログを確認します。
失敗したアーカイブを再利用するか、修正後に再ビルドするかも記録します。成果物のハッシュ値を管理しておくと、同じアーカイブが複数環境へ移動したことを確認できます。
運用開始前のチェックリスト
本番相当のパイプラインを有効にする前に、次の項目を一度通して確認します。
- コミットからアーカイブまでの追跡情報が残る
- ビルドとデプロイのログを担当者が読める
- テスト失敗時に後続デプロイが停止する
- 本番デプロイに承認ステップがある
- 秘密情報がログとアーカイブに含まれない
- ロール変更とDB変更のレビュー担当が明確である
- ロールバックまたは前バージョン復旧の手順を検証している
- SAP HANA cockpitとSAP HANA database explorerで事後確認できる
CI/CDは、導入直後からすべての検査を自動化する必要はありません。まずは再現可能なビルド、テスト失敗時の停止、同一アーカイブの昇格、実行ログの保存を整え、その後に性能検査やデータ品質検査を追加すると、運用負荷を抑えながら改善できます。