CI/CD and Deployment

What the two GitLab pipelines really do, which steps are manual, and how images move to Kubernetes or ECS.

The two repositories have separate pipelines because they produce different runtime images:

api builds the Symfony API image used for admin and member contexts;
agapi-member-booking builds separate web and WebSocket images.

A change that crosses repositories needs two pipeline results and possibly two deployments.

Common pipeline purpose

flowchart LR
    A[Secret and quality scan] --> B[Build image]
    B --> C[Trivy image scan]
    C --> D[Deploy selected environment]

The pipeline definitions contain manual and automatic jobs. A job shown in the graph but waiting for a person is not a completed gate.

Symfony API pipeline

The checked-in api/.gitlab-ci.yml has these stages:

lint — Gitleaks (allowed to fail) followed by SonarQube (required);
build — build and push the API image;
security — scan that image with Trivy;
deploy — apply Kubernetes templates or update AWS ECS task definitions.

Development, test, and stage builds are branch-controlled and several are manual. Production image creation and deployment are tag-based and manual. The same production image can be placed into different ECS services for admin and member API contexts by environment variables and task definitions.

Admin/compatibility pipeline

agapi-member-booking/.gitlab-ci.yml builds and scans the web and WebSocket images separately. Development and stage use Kubernetes manifests generated from templates. Verification and production use AWS ECS task-definition updates.

Development builds/deployments are manual. The test block for web/WebSocket is commented out in the checked-in file. Production builds and deploys are manual; production deploy jobs are tag-gated.

Its final Gitleaks and Sonar jobs are marked allow_failure, so their failure must not be described as a passing required gate.

Environments represented in code

Environment path	How it is represented
Development	Feature/bug/develop branch jobs and development Kubernetes templates.
Test	API test jobs; the admin/compatibility test jobs are currently commented out.
Stage	Release/develop/main rules depending on repository, with stage Kubernetes templates.
Verification / preproduction	Production-style image deployed by ECS task-definition update.
Production	Tag-gated image and ECS service update, with manual jobs.

This table describes pipeline definitions, not proof that an environment is currently healthy or that a particular version is deployed.

Database changes

The repositories contain SQL/bootstrap data and Symfony migration support, but the inspected pipeline YAML does not show a universal automatic doctrine:migrations:migrate step.

For a schema or JSON-shape change, the release plan must state:

which repository owns the migration;
whether old and new services can run during rollout;
how existing JSON records are transformed;
how the change is verified and rolled back;
when the migration is executed and by whom.

Do not claim that deployment automatically migrated the database unless the specific job or operations record proves it.

Reading a pipeline result honestly

Report each item separately:

source commit and branch/tag;
image build result;
required scan result;
allowed-to-fail scan result;
deployment job status (manual, pending, failed, or passed);
target environment and image tag/digest;
runtime health check after rollout;
database migration status;
local test evidence not run by CI.

A built image is not a deployment. A successful kubectl apply or ECS update is not proof that the new containers became healthy. Complete the relevant runtime checks before calling a release finished.