Deployment as a Record

A Hangangjari deployment moves the API called by the App Store app together with workers, DB migrations, Redis cache, forecasts, and push. CI/CD records the order in which these components are applied and the result of each step.

The Hangangjari backend deploys through CI, a container registry, a deploy repository, ArgoCD, and K3s. Each step records the checks, image, and desired state a change passed through.

A Repeatable Deployment Path

Checks, image creation, and desired-state updates run through one fixed pipeline.

sequenceDiagram
  autonumber
  participant Dev as Developer
  participant Git as Git server
  participant CI as CI
  participant Registry as Container registry
  participant Deploy as Deploy repository
  participant Sync as ArgoCD
  participant Runtime as K3s
  participant Smoke as Smoke check

  Dev->>Git: Push change branch
  Git->>CI: Trigger verification
  CI->>CI: Basic checks, tests, API contract checks
  CI->>CI: Generate and validate deploy manifests
  CI->>Registry: Build and publish versioned image
  CI->>Deploy: Update production desired state
  Sync->>Deploy: Read production desired state
  Sync->>Runtime: Apply order and hooks
  Sync->>Runtime: Deploy server and worker processes
  Smoke->>Runtime: Check health and core behavior

Feature branches only verify. Production desired-state updates happen only from the protected default branch, whose permissions prevent experimental branches from deploying to production.

A failure on an experimental branch ends as a verification result and does not change the production image or deploy repository.

Automated Checks Before Deployment

CI checks the build together with these items:

Stage	Purpose
lint	Basic backend code errors
test	API logic tests including Postgres and Redis
localization validate	App string catalog and documented key validation
API shape preservation	API contract and generated artifact preservation
manifest validation	Kustomize/Kubernetes manifest build check
image build	backend image creation
security artifacts	Supply-chain checks such as SBOM, image scan, and signing
deploy repo update	Update image tag in production desired state

These checks cover the API, workers, DB migrations, cache, push, and forecasts that deploy together.

A person reviews the automated-check results and the change impact to decide when to deploy.

Server Configuration in a Separate Repository

The application code repository and production desired state are separated. CI builds an image and updates the image tag in the deploy repository. ArgoCD reads the deploy repository and reconciles K3s runtime state.

flowchart LR
  AppRepo["Application repository"] --> CI["CI pipeline"]
  CI --> Image["Versioned image"]
  CI --> DeployRepo["Deploy repository<br/>desired state"]
  DeployRepo --> Sync["ArgoCD"]
  Sync --> Runtime["K3s cluster"]

The repository split leaves these records independently traceable.

• Code commits remain traceable to deployment images.
• Production manifest changes and app code changes can be separated.
• Rollback means returning to a previous desired state.
• ArgoCD shows drift between actual cluster state and desired state.

When investigating the start of an incident, an operator can trace the code commit, image, desired state, and K3s rollout along one path.

Deployment Order for Migrations and Workers

A backend deployment must align the DB schema, bootstrap jobs, API, and workers in order.

ArgoCD sync phases and waves specify the order of migration, bootstrap, and rollout.

flowchart TB
  Wave1["Pre-sync<br/>migration or bootstrap"] --> Wave2["Core services<br/>Postgres Redis API"]
  Wave2 --> Wave3["Workers<br/>parking outing forecast push"]
  Wave3 --> Wave4["Smoke check<br/>health · feature freshness"]

CI repeatedly handles image creation and desired-state updates. Deployments that move DB migrations, worker rollouts, and source-data collection together require a scope review before sync and a smoke-result review afterward.

Different Timelines for iOS and Server Releases

iOS apps and the backend follow different release cycles. The server can change in minutes, while the app passes through App Store review and user update cycles.

API contracts therefore follow these compatibility rules.

• Do not break DTOs already deployed.
• Distinguish optional field additions from required field changes.
• Account for a period where app versions are mixed.
• Server changes can turn on before app rollout.
• Widgets can see snapshots older than the app screen.

DTOs explicitly include metadata such as generated_at, observed_at, freshness, and status. Here, freshness tells how current a value is, and unknown values do not map to a success state.

Following Changes Through Deployment Records

CI jobs verify API shapes, manifests, images, and supply-chain artifacts, then record K3s desired state in the deploy repository. The same path exposes migration and worker rollout order and smoke results. Because iOS passes through App Store review and user update cycles, server DTOs preserve their existing meaning across that compatibility window.