A quality gate is a pipeline control that allows an API change to progress only when its inputs satisfy defined criteria. It replaces inconsistent, late review with fast checks at a delivery stage, while leaving governance teams to review proposals that pass the required controls. section 8.6 section 1.1
For an API design proposal at the source-control pull-request stage, define the gate around:
- Inputs: OpenAPI definition files, draft API-guide Markdown files, and a work-ticket reference. section 8.6
- Minimum outputs: no error-level API linting problems, breaking changes, or API-documentation problems. section 8.6
- Controls: API linting, code-owner approval, breaking-change checks, documentation checks, and any project-specific validations such as client-SDK generation. section 8.6
- Actors and actions: API designers raise pull requests; governance teams review, approve, and merge proposals that pass. section 8.6
Security threshold in a deployment pipeline
A GitHub Actions workflow can run a 42Crunch API-definition audit during deployment. The audit scores security from 0 for insecure APIs to 100 for no detected problems; configuring a minimum passing score makes the result a security quality gate and links each run to a detailed report. The checks cover authentication, authorization, transport, and data payload practices. section 8.11.6
Table 8.1 Governance model for API design proposals at the source stage of a deployment pipeline
|
Aspect
|
Details
|
|||
|---|---|---|---|---|
|
Objective
|
Enables fast feedback for API designers on objective API style guide checks
|
|||
|
Inputs
|
API design proposal:
• OpenAPI definition files
• Draft API guide documentation Markdown files
• Work ticket reference
|
|||
|
Outputs
|
An API design proposal that meets minimum design review criteria:
• No error-level API linting problems
• No breaking changes
• No error-level API documentation problems
|
|||
|
Actors
|
• API designer
• API governance team
|
|||
|
Trigger
|
PR raised
|
|||
|
Actions
|
• Raise a PR
• Review, approve, and merge PRs
|
|||
|
Risks and Controls
|
Risk
|
Mitigation
|
Control
|
|
|
API consistency
|
Check that OpenAPI definitions comply with the organization’s API style guide.
|
• PR build API linting
• Code owners approval
|
||
|
Disruptive breaking changes
|
Check that API design changes don’t introduce unplanned breaking changes.
|
PR build breaking change checks
|
||
|
Difficult to read API documentation
|
Check API guide documentation for punctuation and grammatical errors.
|
PR build prose linting
|
||
|
Lack of feature change traceability
|
Provide product features and release information metadata required for PR review context.
|
PR description policy checks
|
||
Use the governance model to map each pipeline stage to objectives, inputs, outputs, actors, triggers, risks, and controls. section 8.6
