CI/CD¶

Continuous integration keeps every change buildable and tested. Continuous delivery produces a deployable artifact and promotes it through controlled environments.

Pipeline stages¶

1. Checkout the root repository and submodules.
2. Validate formatting, documentation links and configuration.
3. Build and test each changed service.
4. Build a container image and scan it for vulnerabilities.
5. Tag the image with an immutable commit or release identifier.
6. Push the image to the container registry.
7. Deploy to a non-production environment.
8. Run smoke and integration tests.
9. Require approval before production promotion.
10. Publish deployment, test and rollback evidence.

Each runnable service repository owns its CI/CD workflow: account, auth, gateway, and order-service run lint, format, tests, coverage quality gates, CodeQL, and publish an immutable GHCR image tagged with the source commit. The order contract runs the same checks except image publishing because it is a library.

The platform repository owns cross-service validation and deployment coordination. Its integration job pulls sha-<submodule-commit> images from GHCR and builds only when the matching image is unavailable.

Pipeline rules¶

• Do not use latest as the only deployment identifier.
• Do not print secrets in workflow logs.
• Pin or review action versions.
• Cancel superseded work where safe.
• Make migrations backward-compatible and observable.
• Keep a previous image available for rollback.
• Ensure deployment status and commit SHA are visible.
• Grant service workflows packages: write and the platform workflow packages: read.

Deployment verification¶

After deployment, verify Gateway health, authentication, product retrieval, order creation and currency conversion. Record the deployed versions of all services, not only the Gateway image.