Skip to content

DevOps lifecycle

The lifecycle connects product decisions, code changes, artifact delivery and observation of the result. Each phase produces evidence for the next iteration. Its conceptual order does not necessarily match CI stage names: the image is built and published by the same job, and source analysis occurs before image construction.

From planning to operations

Phase Team activity Implementation and evidence Relevant boundary
Plan Define tasks, milestones and priorities Thesis and 12 public issues accessed on 26 October 2026 Nine closed, three open; infrastructure milestone remains active
Code Edit code, manifests and IaC Separate repositories; historical use of the editor and Web IDE The complete MR review policy is not described in code
Build Compile and package Maven produces the JAR; Docker builds the image -DskipTests skips tests in the packaging job
Test Analyse quality and security GitLab templates and JSON report parsers Result parsers share allow_failure: true
Release Make the artifact available Push to GitLab Container Registry with a SHA reference No semantically versioned GitLab Release object is created
Deploy Promote and apply a version Commit to the manifest repository and kubectl apply One target per run; no explicit rollout wait in the job
Operate Inspect resources and perform changes GitLab Agent, CI contexts and Kubernetes resources Actions depend on RBAC and agent permissions
Monitor Observe execution and feed tasks back Logs/events, probes and historical OTLP ingestion evidence No application OTLP instrumentation was found in the reviewed repositories

Observed planning

The public inventory retains four milestones: application preparation, pipelines and manifests are closed; infrastructure is active. The three open issues belong to IaC. A historical task mentions Azure, but the code implements AWS and GCP; that card does not extend the delivered scope. The thesis map explains this distinction between planning and implementation.

Traceability chain

The image reference follows this expression:

$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA

update-k8s-manifests replaces the image in deployment.yaml and creates a commit whose message is the application's SHA. deploy clones the manifest repository's main again and applies its files to the selected target. Investigating a delivery requires preserving the relationship between source commit, pipeline, image reference, manifest commit and cluster.

This chain identifies the requested deployment. It does not establish that every pod completed the change or pin the image by digest: the final job runs kubectl get all, but not kubectl rollout status. A green pipeline should be supplemented with operational verification.

Execution conditions

The current deployment template runs promotion and application jobs when the branch is protected main. Its rules contain no when: manual; both run automatically when their conditions hold. The thesis contains an earlier manually promoted version, recorded in the thesis differences.

Infrastructure behaves differently: create selects validation, planning and application; apply jobs are manual on main, with allow_failure: false. Each root must complete before the next proceeds. destroy actions follow the reverse order and also require manual application. Read the infrastructure pipeline before starting a run.

Quality, secret and container analyses include protected-branch conditions and enablement variables. SAST is inherited from an external GitLab template; its complete behaviour depends on the template resolved by the instance. The quality and security guide distinguishes local and inherited jobs.

Two connected cycles

Infrastructure need not be rebuilt for every frontend text change. While its contracts remain valid, a new image can be deployed onto the existing cluster. Changes to networking, database configuration, cluster version or platform bootstrap follow the IaC pipeline and must be assessed through its plan.

The application depends on the namespace, secrets, agent context and network created or configured during bootstrap. The first-deployment guide therefore establishes the foundation, verifies access and then allows application pipelines to run.

Closing an iteration

After deployment, verify pod availability, startup errors, database access and the user-facing functional path. Record failures as new tasks linked to the commit and run. An application rollback must change the versioned reference and reapply it; it does not automatically revert MySQL schema or data.

Documentation maintenance belongs to the same cycle: changes to contracts, variables and procedures should be reflected in both languages and pass the documentation publishing pipeline.

Sources