Skip to content

Design decisions

This record explains the choices defining Cloud Delivery Lab. Confirmed means the thesis states a rationale and the code connects it to an implementation. Observed means the behaviour exists in code, but no unstated intention is attributed to the author. Proposed improvements are kept separate from existing capabilities.

Decisions with documented rationale

D01. GitLab as a shared working interface

Status: confirmed. The thesis aims to reduce fragmentation across planning, code, automation, artifacts and operations. The group brings together repositories, templates, Registry, states and agents.

The intended benefit is simpler traceability and fewer external integrations to maintain. The tradeoff is dependence on GitLab capabilities, permissions and evolution. Centralising work does not make every operational action available in the interface: the thesis acknowledges limits for advanced Kubernetes operations.

Evidence: thesis PDF 16–18 and 62–66; printed 10–12 and 56–60. Repository map.

D02. Separate application, manifests, CI and infrastructure

Status: confirmed. Applications produce artifacts; deployment repositories preserve the desired version; cicd-templates standardises delivery; terraform-modules provisions its cloud foundation.

This separation supports independent review of responsibilities and tracing a code change to its manifest. It also requires cross-project permissions and consistent contracts. Frontend and backend currently deliver independently; their promotion is not transactional.

Evidence: thesis PDF 29–30; printed 23–24; promotion and application template.

D03. Reusable CI templates

Status: confirmed. Both application projects include the same templates to avoid duplication and share criteria. The thesis proposes applying this pattern to additional projects.

Current includes use ref: main. This lets subsequent runs adopt template changes without editing each application, but makes historical configuration harder to reproduce from an application commit alone. Pinning tags or SHAs is a possible evolution, not current behaviour.

Evidence: thesis PDF 35–36; printed 29–30; backend includes.

D04. Traceable images in GitLab Registry

Status: confirmed. Images use the normalised branch and source SHA. The thesis emphasises linking artifacts to changes and integrating authentication with CI.

The reference helps identify and reselect a version. SHA tagging does not itself establish an immutability policy or guarantee indefinite retention; rollback depends on availability and pull permissions.

Evidence: thesis PDF 42–48; printed 36–42; image construction and push.

D05. Small application and native Kubernetes manifests

Status: confirmed. A simple frontend, backend and MySQL example keeps effort focused on DevOps. Native YAML manifests reduce packaging complexity in the demonstrator.

The promotion template handles values.yaml when it finds Chart.yaml, but the deployment job exits with an error for a chart. Helm is therefore not documented as a working application-delivery alternative. Helm is used for platform components such as GitLab Agent.

Evidence: thesis PDF 31–32 and 56; printed 25–26 and 50; manifest and chart handling.

D06. Four IaC roots per provider

Status: confirmed. Networking, Kubernetes, database and platform separate domains and dependencies. The platform is applied to an already-created cluster.

Independent states support explicit provisioning and teardown ordering. They also introduce output and credential dependencies across roots; recovery must preserve coherence between the four states. They are not eight entirely independent environments, but four layers of each cloud implementation.

Evidence: thesis PDF 50–55; printed 44–49; infrastructure DAG and states.

D07. Private nodes, NAT egress and lab sizing

Status: confirmed in general intent. The thesis explains private nodes as a way to reduce direct exposure and NAT as a way to reach external services. It explicitly justifies AWS t3.small by its limited cost.

The code keeps databases private, but cluster management endpoints default to public access. Node privacy and API-server access restrictions are separate decisions. Small instance sizes are not a production capacity test; regional GKE configuration must be assessed by total nodes and zones.

Evidence: thesis PDF 49–55; printed 43–49; EKS defaults and GKE defaults.

Observed behaviours without assumed rationale

ID Observed choice Effect Explanation status
D08 OpenTofu executes .tf configurations CI image includes OpenTofu 1.12.1; the thesis already mentions it Reason for choosing this executor awaits author confirmation
D09 Infrastructure starts with destroy and pro Operators must review action and environment when launching a pipeline Not assumed to be a recommended everyday default
D10 Automatic application deployment on protected main No manual approval in the current template The thesis also shows an earlier manual design
D11 Security result parsers allow failure exit 1 for High/Critical is not a mandatory blocking gate Rationale for non-blocking results is not documented
D12 GKE receives an AWS Ingress manifest External exposure is not reproducible from that file alone Possible external configuration needs clarification
D13 ENVIRONMENT changes state names It does not automatically separate cloud names and tags A complete dev/pre/pro isolation model is not documented
D14 Telemetry examples in GitLab Historical ingestion evidence, not versioned instrumentation configuration Signal origin and scope still need documentation

Open questions remain open: no cost, licensing, urgency or personal-preference rationale is assigned without evidence. Findings records the operational impact, and sources defines the review scope.

Proposed evolution

Proposal Required decision
Version CI templates and tools Update cadence, compatibility and promotion ownership
Define security gates and functional tests Blocking criteria, exceptions and their approval record
Create provider-specific exposure configuration Hostnames, certificates, controller and overlay strategy
Fully parameterise environments Resource identity, accounts/projects, networks, states and permissions
Implement reproducible observability Signals, retention, export and service objectives
Add rollout waiting and smoke tests Criteria for considering delivery successful

This documentation repository implements another evolution: bilingual Markdown published through MkDocs/Pages. Its publishing pipeline is new relative to the reviewed application repositories.

Sources