Quality gates in the pipeline

A quality gate is a check that change must pass before it moves on. Gates turn good intentions ("we should run ATC", "we should write tests") into rules that hold under deadline pressure. For clean core, the essential gates are static checks of how code is built, automated tests of what it does, and contract checks at the boundaries, placed where they stop problems earliest.

ATC as the clean core gate

The ABAP test cockpit (ATC) is SAP's static check framework, and SAP names it as the key tool for code-level clean core governance. In SAP S/4HANA 2023 and 2025, clean core checks are available in ATC; a practitioner guide from SAP PRESS describes using a check variant based on ABAP_CLOUD_DEVELOPMENT_DEFAULT, whose "Usage of APIs" check uses SAP's object classifications (published in SAP's Cloudification Repository on GitHub) to say whether code uses released, classic or internal objects. SAP Notes govern the setup on each release, so follow the current notes for yours. Systems below SAP S/4HANA 2023 can be checked with a central ATC on SAP BTP.

ATC can run automatically when a transport request is released and block the release when findings exceed a priority threshold. The same guide reports SAP's recommendation to block on priority 1 and 2 findings, with level C and D findings blocking by default and level B findings reported as non-blocking priority 3 messages. By default the check runs at request release; checking at task release is optional and adds overhead. Treat these defaults as a starting point and confirm them in your system.

Exemptions without erosion

Some findings can't be fixed now: legacy code converted from ECC, or a level C access with no released alternative yet. ATC supports exemptions with approval. Used well, an exemption is a recorded, time-limited decision with a reason and an owner. Used badly, it is a way to make the gate green. Report exemptions on the governance dashboard and review them each release; a growing exemption list is a clean core trend in the wrong direction.

Gates for side-by-side

BTP extensions follow a pipeline instead of transports. Contoso's portal pipeline runs unit and CAP service tests on every commit, contract checks against the API specification on every build, provider verification against the S/4HANA quality system before deployment to the BTP test space, and a small end-to-end suite before production. When S/4HANA itself changes (a feature pack stack, a fix to a custom OData service), the contract and end-to-end checks run again from the S/4HANA side, too.