Skip to content

The project

Cloud Delivery Lab demonstrates how to manage an application's DevOps lifecycle from GitLab: planning, editing code, building, validation, publishing images, provisioning infrastructure, deployment and operations. Terraform defines resources and OpenTofu executes plans in CI. AWS and Google Cloud provide two infrastructure implementations for the same demonstration application.

This documentation describes the public code reviewed on 26 October 2026. The group's display name is Cloud Delivery Lab; its path remains gabriel-canals-tfm. Evidence links are pinned to the commits examined. The review does not establish whether historical accounts, clusters, images or endpoints remain active.

What it provides

The project connects responsibilities often maintained separately: source code, automation templates, images, runtime manifests and infrastructure state. A change can be linked to its source commit, the resulting image and the commit that updated its Kubernetes manifest.

GitLab is the working interface and coordination system. Jobs run specialised tools—Maven, Docker, OpenTofu and kubectl—while cloud providers host the resources. Centralisation describes where the lifecycle is coordinated; it does not remove those tools' APIs, credentials or dependencies.

Capability Versioned implementation Further reading
Application code and delivery Two Java projects, Dockerfiles and CI entry points Demonstration application
Shared automation build.yml, test.yml and deploy.yml Pipelines
Traceable artifacts JAR as an artifact; image tagged with branch and SHA Build and release
Desired state Two repositories containing Kubernetes manifests Deployment
Infrastructure Four configuration roots per provider Infrastructure
State and cluster access GitLab HTTP backend and GitLab Agent State, access
Documentation This MkDocs repository, English and Spanish, with a Pages pipeline Publishing

The application as a demonstrator

The example is a user-management application composed of a Java frontend, a Java API and MySQL. It tests whether an image can be built, configuration reaches the container and the application can access a private database. Its business logic is not the project's focus.

The current manifests create the web and rest Deployments in app, with one replica per component. Both use port 8080 at runtime. The frontend Dockerfile declares EXPOSE 8081, but Spring configuration and the manifest use 8080: the Dockerfile declaration does not change the process's listening port.

What multicloud means here

Separate roots implement AWS/EKS/RDS and GCP/GKE/Cloud SQL. The infrastructure pipeline selects a provider through CLOUD_PROVIDER; the application pipeline selects a cluster through DEPLOY_TARGET. The application projects reviewed set DEPLOY_TARGET: gke.

Each deployment run targets one cluster. The code does not implement database synchronisation, cross-provider failover or atomic promotion to both clouds. Sharing an automation model supports comparison and deployment to either destination; it does not by itself establish an active-active architecture.

Scope and maturity

The thesis presents the work as a foundation for development and preproduction, acknowledging limitations when moving to larger systems. The code retains lab choices that require review before a new reproduction: infrastructure defaults of destroy/pro, resource names shared across environments, public API-server access, security result jobs that allow failure and an AWS-specific ingress.

Findings and open points explain their practical effects. No infrastructure changes, deployments or tests against the author's accounts were performed while preparing this documentation.

Reading paths

Sources