Skip to content

Relationship to the thesis

The contextual source is Gabriel Ángel Canals Salleras's thesis, Automatización multinube con Terraform gestionada íntegramente desde GitLab: una propuesta de plataforma DevOps centralizada, with a stated submission date of 29 June 2026. The supplied file contains 68 PDF pages. This documentation reorganises its content for reference and operations, comparing it with the six public repositories reviewed on 26 October 2026.

Page and source conventions

In the main body, PDF page = printed page + 6: PDF page 7 corresponds to printed page 1; PDF page 66 to printed page 60. Preliminary pages and the bibliography use different numbering. Both references are provided so evidence can be located independently of the viewer.

The thesis supplies objectives, rationale and historical screenshots. SHA-pinned links supply the versioned behaviour examined. Public GitLab history supplies execution and task states as of the access date. None of these sources alone proves the current state of a cloud account.

The original thesis is not included in the public site: this page locates its sections in the author's source file. The commit inventory is available under sources.

Content map

Thesis section PDF / printed Content carried forward Documentation page
6.1 General objective and comparison 16–18 / 10–12 Centralisation and project rationale Project, decisions
6.2 Specific objectives and requirements 19–22 / 13–16 Scope, capabilities and criteria Matrices on this page
6.3 Methodology 23–24 / 17–18 Eight lifecycle phases DevOps lifecycle
7.1 Planning 25–28 / 19–22 Milestones, issues and work distribution DevOps lifecycle
7.1.1 Hierarchy 28–30 / 22–24 Responsibilities and repositories Repositories, architecture
7.2.1 Application 31–32 / 25–26 Java/MySQL demonstrator Application
7.2.2 Code editing 33–34 / 27–28 Editor and Web IDE DevOps lifecycle
7.2.3 Pipelines 35–40 / 29–34 Includes, jobs and responsibility boundaries Pipelines
7.2.4 Build 41–44 / 35–38 Maven, JAR, Dockerfiles and images Build and release
7.2.5 Test 44–45 / 38–39 Quality, security and report interpretation Quality and security
7.2.6 Release 46–48 / 40–42 Registry and commit references Build and release
7.2.7 Infrastructure 49–56 / 43–50 AWS, GCP, agents, states and provisioning Infrastructure, AWS, GCP
7.2.8 Deploy 56–58 / 50–52 Manifest updates and application Deployment
7.2.9 Monitoring 59–61 / 53–55 Logs, events and telemetry examples Observability
7.2.10 Evaluation 61–63 / 55–57 Results and limits Project, findings
8.1 Conclusions 64–65 / 58–59 Feasibility and production boundaries Decisions
8.2 Future work 66 / 60 Greater complexity, advanced operations and automated documentation Decisions, publishing

Functional requirements and evidence

RF identifiers come from table 2, PDF 20–21 / printed 14–15. The scope column records what the documentation supports; it is not a certification of present operation.

RF Capability Evidence and boundary
RF-01 Plan in GitLab Thesis and 12 public issues examined; some planning items remain open
RF-02 Separate artifacts Six repositories with distinct responsibilities
RF-03 Edit from GitLab Editor/Web IDE screenshots and description; history does not prove which editor was used for every commit
RF-04 Build the application Maven jobs and successful latest public runs
RF-05 Create containers Dockerfiles and generate-image
RF-06 Publish to Registry Push command and SHA references; current image download was not tested
RF-07 Quality and security Scanners and parsers; observed result jobs are non-blocking
RF-08 Update manifests update-k8s-manifests, commit and push
RF-09 Provision infrastructure .tf roots, OpenTofu pipeline and historical evidence; no new run during this review
RF-10 Two providers AWS and GCP implemented; one destination per application run
RF-11 Manage state in GitLab HTTP backend, CI configuration and state screenshot
RF-12 Operate Kubernetes Two agent configurations and screenshots; current access depends on connection and permissions
RF-13 Monitor Probes/logs/events; OTLP examples without complete versioned instrumentation
RF-14 Iterate on commits Application CI history and automatic promotion on protected main
RF-15 Recover an earlier image Versioned references; reapplication and separate data handling are required

Non-functional requirements and scope

RNF identifiers come from table 3, PDF 22 / printed 16.

RNF Property How it is represented and what needs qualification
RNF-01 Centralisation Coordination in GitLab; cloud bootstrap and some configuration remain prerequisites
RNF-02 Reproducibility Versioned code and pipeline; external defaults, floating tools and secrets need preparation
RNF-03 Traceability Code SHA, image and manifest commit; delivery job lacks functional validation
RNF-04 Maintainability Shared templates; main references propagate changes to subsequent runs
RNF-05 Separation of concerns Application, delivery and IaC are separate; cross-project contracts are documented
RNF-06 Portability AWS/GCP implementations; ingress and provider-specific details require adaptation
RNF-07 Idempotence Remote state and plans; no new convergence test was run for this package

Differences and clarifications

Topic Thesis Reviewed code or public evidence
Manual promotion PDF 39 / 33 shows when: manual; PDF 57–58 / 51–52 describes automation Current template is automatic on protected main
Build/Test ordering The narrative separates successive phases Stages analyse source before Build and images afterwards
IaC executor Terraform as the technology; OpenTofu mentioned on PDF 51 / 45 OpenTofu 1.12.1 in the CI image; this is not a contradiction
Frontend port Dockerfile EXPOSE 8081, PDF 43 / 37 Spring configuration and manifest listen on 8080
Vulnerability blocking Parser returns an error for High/Critical Parser base allows failure; it is not a mandatory gate
Multicloud coverage Both clusters and deployment to two providers One destination per run and application repositories selecting GKE; existing Ingress is AWS-specific
Telemetry Trace/metric examples, PDF 59 / 53 No OTLP instrumentation configuration found in the six repositories
Planning Planned dates and completed implementation narrative Infrastructure milestone remains active; its public due date is 15 June, compared with 10 June in the historical table

The code also reveals operational details not developed fully in the thesis: HTTP backend and cross-state authentication; saved plans; concurrency groups; teardown ordering; a job removing a Private Service Access state entry; an unprovisioned Registry secret; TCP probes; effective MySQL parameters; agent permissions and incomplete environment separation. Their technical pages and findings document these details.

Public planning and execution history

The 26 October 2026 lookup returned 12 public issues: 9 closed and 3 open in the IaC project. Their metadata contains four milestones: three closed and infrastructure active. One open task historically references Azure, but the reviewed repositories contain no Azure implementation; implemented scope remains AWS and GCP.

The latest public frontend and backend pipelines match their examined HEADs and contain 11 successful jobs. The latest visible infrastructure pipeline is a teardown, belongs to an earlier commit than HEAD and does not establish a currently active deployment. This documentation distinguishes these facts from the thesis's historical screenshots.

Sources