CI/CD Pipeline Standard

Every Flexso BTP repo uses the standardized .gitlab-ci.yml that /spexso-cicd-init generates — either as a thin include: of the shared CI template (central-managed, the default: fixes reach every product on its next pipeline) or as a full copy in the repo (project-managed). The model is trunk-based development with tag-based releases:

• main is always releasable. Short-lived feature branches merge fast via squash MRs; risky features ship dark behind feature flags configured per environment in mta_ext/<env>.mtaext.
• Nothing untested is built, released or deployed. test gates every MR and main; release-gate runs the same script on the tag. The commands come from .spexso/config.json, so CI runs what the agent runs.
• Deploying ≠ releasing. Every merge to main deploys DEV (MRs do not deploy). A release is an immutable vX.Y.Z tag on main, cut by the manual prepare-release job.
• Releases are fully automated. Version bump (package.json + mta.yaml + manifest.json), CHANGELOG.md, tag, and GitLab Release are handled by commit-and-tag-version + the pipeline. Conventional Commits determine the bump.

Pipeline flow

Stage	Jobs	When
test	test (unit + service suite + static checks), release-gate (same, on the tag), journeys (OPA5/wdi5)	MR to main, main / tag / scheduled
build	build (mbt → .mtar)	MR to main, main, tag
release	prepare-release (manual: bump + tag), create-release (GitLab Release)	main / tag
deploy	deploy-dev (auto, main only), deploy-tst (auto on tag), deploy-prd (manual gate on tag)	see design/cicd

The same .mtar built on the tag is promoted TST → PRD — no rebuild, no drift between what QA tested and what production runs.

Conventions

• Commit messages follow Conventional Commits (feat:, fix:, chore:, …) — they drive the version bump and the changelog. /spexso-finish derives the MR title type from the issue's type:: label automatically.
• Never tag manually; never move or delete a release tag (protected tags on v*).
• The version is only ever changed by commit-and-tag-version.
• production is a protected environment with a blocking manual gate.
• Set APP_URL_<ENV> per environment: it links the app on the Environments page and smoke-checks it after every deploy.
• In central-managed mode, pin a major ref (v1) — never main — and prefer variables over redefining a job.

See CI/CD design for the full trigger model and the setup scenario for the walkthrough.