SAP HANA Development CI/CD Basics: Build a Reliable MTA Pipeline

SAP HANA development CI/CD connects source control, MTA builds, automated validation, deployment, and operational checks into one repeatable workflow. The goal is to make database artifacts and application code move through environments with traceable changes and predictable recovery steps.

For on-premise SAP HANA systems, the pipeline should treat HDI containers, database artifacts, application services, credentials, and environment-specific configuration as separate concerns. A successful build is not enough: the deployment must also be observable, testable, and reversible.

01Define the delivery boundary

Start by documenting what the repository delivers. A typical project may contain CDS models, calculation views, SQLScript procedures, table definitions, application code, service configuration, and an mta.yaml descriptor. Keep runtime secrets and production-specific values outside the repository.

Use a clear ownership model for each artifact. Developers own source changes and unit tests, the pipeline owns repeatable builds and validation, and the operations team owns destination credentials, deployment windows, monitoring, and recovery procedures. This division makes failures easier to diagnose.

The SAP HANA development overview provides useful context for positioning SQLScript, CDS, calculation views, and HDI-based development within the wider development landscape.

02Use a controlled branch and promotion model

A practical workflow uses short-lived branches, pull-request review, and a protected main branch. Every merge should produce an identifiable commit or release artifact. Promote the same built artifact between environments instead of rebuilding independently for each target.

Separate environment configuration from application content. Store destination names, container bindings, feature switches, and test data settings in deployment-specific configuration managed by the delivery platform. Keep passwords, private keys, and technical-user credentials in a protected secret store.

Define promotion gates before implementation. Common gates include successful compilation, static checks, unit tests, artifact inspection, deployment to a disposable or integration environment, smoke tests, and an approval for production.

03Build the MTA artifact consistently

The build stage should run in a controlled agent with pinned tool versions. Install the project dependencies, validate the descriptor, compile the modules, and produce one versioned multi-target application artifact. Record the source commit, build number, tool versions, and dependency versions with the artifact.

A representative build sequence is:

npm ci
mbt build

The exact commands depend on the project layout and build tooling, but the pipeline should always fail on a nonzero exit code. Do not allow a partially built archive to continue to deployment.

Inspect the generated archive before publishing it. Confirm that expected modules are present, development-only files are excluded, and configuration does not contain credentials. The SAP HANA HDI containers guide is a useful companion when the project deploys database artifacts through an HDI container.

04Validate database artifacts before deployment

Run fast validation as early as possible. Syntax checks and dependency validation catch problems before an environment is changed. For SQLScript, test procedures and table functions with representative inputs, including empty results, null values, boundary dates, and authorization-sensitive paths.

For calculation views and CDS-based models, validate activation dependencies and test the output contract expected by consuming applications. A model that activates successfully can still produce incorrect results when filters, joins, cardinalities, or analytic privileges are misconfigured.

Keep test data deterministic. Seed only the data required for the test and clean it up after execution where the environment is shared. Never make production data a hidden dependency of an automated test.

The SAP HANA SQLScript procedures guide and SAP HANA table functions guide can be used to organize database-focused checks around procedure and table-function behavior.

05Add application and integration tests

Unit tests should verify isolated logic, while integration tests should verify communication between the application, HDI container, database objects, and required services. Keep the test layers separate so a failed integration environment does not obscure a deterministic unit-test failure.

Include negative cases in the suite. Test invalid input, missing records, insufficient privileges, duplicate requests, transaction rollback, and repeated execution. These cases reveal defects that a successful-path test cannot detect.

Use smoke tests immediately after deployment. A small set of checks should confirm that the application starts, the expected database objects are available, a basic read succeeds, and a representative write follows the intended transaction behavior. The SAP HANA application testing and debugging guide covers practical approaches for isolating failures during this stage.

06Deploy with explicit gates

Deploy first to an integration environment that resembles production in database structure, service bindings, authorization design, and configuration shape. Capture deployment logs and the resulting application and database revision identifiers.

Before production deployment, verify the change record, artifact checksum, target system, backup status, maintenance window, test results, and rollback procedure. A deployment job should require an explicit target and should stop when the target does not match the approved environment.

Use least-privilege technical users for pipeline actions. Separate build permissions from deployment permissions, and restrict production deployment credentials to the job or release process that requires them. Record who approved the release and which artifact was promoted.

07Monitor the release and recover safely

After deployment, monitor application availability, database errors, failed requests, resource pressure, and relevant traces. SAP HANA cockpit and SAP HANA database explorer are useful for inspecting database health, deployed objects, SQL execution, and operational symptoms during validation.

Define rollback by change type. A reversible application change may be restored by redeploying the previous artifact. A database change that alters data or structure may require a forward-fix, a migration script, or a tested restore procedure. Do not assume that replacing application code reverses a database migration.

Keep deployment logs, test reports, artifact metadata, and approval records for the period required by the organization. These records reduce investigation time when a defect appears after several releases.

08Troubleshoot common pipeline failures

Build failure: inspect the first failing module, dependency lock files, tool versions, and descriptor validation output. Reproduce the build with the same agent image or container used by the pipeline.

Activation failure: check object dependencies, deployment order, schema ownership, and the database user or container binding used by the deployment. Review the deployment log before changing source code.

Authorization failure: identify the connection user, container, object owner, and required privilege. Test the same operation with the same technical identity used by the pipeline rather than an administrator account.

Smoke-test failure: compare the deployed artifact identifier with the approved release, then inspect application logs, database errors, service bindings, and recent configuration changes.

Intermittent integration failure: check shared test data, concurrent deployments, service availability, timeouts, and cleanup behavior. Make the test environment observable before increasing retry counts.

09Make the pipeline maintainable

Keep pipeline stages small enough to diagnose and strict enough to protect the target system. Cache dependencies only when the cache is keyed by lock-file content and tool version. Publish test reports even when a later stage fails.

Review deployment permissions, secrets, agent images, and retention settings periodically. Rotate credentials through the secret-management process and verify that old credentials no longer work. Test the rollback procedure in a nonproduction environment after changes to the deployment process.

Measure lead time, build success rate, deployment failure rate, recovery time, escaped defects, and flaky-test frequency. These measures identify whether the pipeline is reducing operational risk rather than merely automating commands.