An API team can deploy services frequently yet still handle API definitions, governance checks, and gateway configuration by hand. A deployment pipeline brings those artifacts into the same repeatable delivery workflow as the service. Continuous integration (CI) regularly integrates changes, builds deployable artifacts, and runs fast technical tests. Continuous delivery (CD) then automates deployment of those artifacts to test or production environments. section 8.3 section 1.2
Keep API definitions and configuration in Git so changes can be reviewed and checked before deployment. A pull-request build can validate the PR title, lint the API definition with Spectral, and check for breaking changes with Tufin/oasdiff. A PR template can ask for the reason for the change; code-owner approval can require a governance reviewer before merge. Automated checks shorten feedback loops, but they do not replace that review. section 8.3 section 1.7
After an approved change reaches the main branch, a build pipeline can:
- Check out the source, compile and test the service, package its executable, and store the resulting artifact. section 9.1.1
- Build a Docker image and push it to a container registry so downstream environments can retrieve it. section 9.1.1
- Bundle a multifile API definition, filter internal endpoints and unused components, lint the resulting definition, and store API artifacts. section 9.1.1
- Continue into deployment and testing: deploy the service and API gateway configuration, then test whether the implementation conforms to the API design. section 9.0
A GitHub Actions build
Create .github/workflows/build.yaml with a push trigger for main. Give its build job repository-read and package-write permissions, then add steps to check out code and build a .jar. Subsequent steps can push the Docker image to GitHub Container Registry and use Redocly CLI to bundle the OpenAPI definition. The PR build and this post-merge build serve different decisions: whether a change may merge, and which artifacts to produce from the merged change. section 9.1.1 section 8.3
Listing 9.1 Creating a GitHub workflow file to run
name: Deployment pipeline
on:
push:
branches:
- main
env:
GITHUB_RUN_NUMBER: ${{ github.run_number }}
The workflow trigger shows when the post-merge build runs: a push to main. section 9.1.1
The operational goal is not automation for its own sake. Git-based approvals and pipeline checks make API standards visible earlier, while automated deployments reduce manual handoffs. Keep the governance rules explicit: a successful build establishes that its configured checks passed, not that every API design decision was sound. section 1.7 section 8.3
