Deployment Architecture, Shared CI/CD Platform, and Canary with Automatic Rollback

You're designing the deployment architecture for ĂnNhanh, a food delivery platform in Vietnam where eight product teams each ship their own way and a bad release during lunch rush costs real money.

What you're practicing: deployment architecture as a trade-off space, not a recipe — the commit-to-production path, where the gates sit, and the rollout strategy chosen for one service's actual risk profile. A shared CI/CD platform built as a reusable pipeline framework that eight teams adopt. Canary deployment with automatic rollback, wired to live metrics so a broken release stops before it reaches every city. The applied build is small — a budget alarm and a sandbox-scale canary demonstration with managed AWS primitives. The substance is the architecture, the framework, and the judgment behind the trade-offs.

What you're learning about the loop: AI writes deployment architectures the same way every time — blue/green everywhere, default pipeline, every rule pushed into memory because memory is the easiest thing to write. It does not see the team size, the change frequency, the latency budget, or the edge targets. It will configure the canary's pieces individually and leave the integration broken, so the system reports a clean deploy while the application degrades. The most useful work you do here is deciding what AI does not see, and proving the rollback actually fires.

Your Role

After this project you can design a deployment system for an organization, not just a pipeline for a service: weigh velocity against risk against blast radius, treat a shared platform as a product its users have to want to adopt, and build a canary you have tested by breaking it.

Last project you designed organizational governance artifacts calibrated to a real team. This time the client is an expert who has built shared deployment infrastructure before and will push back on lazy answers. Almost nothing is provided. You run the discovery, design the architecture from the constraints you surface, and defend the trade-offs. You also decide, per rule, whether it belongs in memory, a skill, or a hook — the AI relationship is part of the deliverable now, and the wrong choice gives false confidence.

What's New

Last time, at Nile Health Group in Egypt, you designed an IaC standards framework, a multi-account topology, a canonical module, and a migration plan for an 8-hospital network — organizational artifacts in formal email, ratified by a terse senior colleague.

This time deployment reaches its summit. The unit of design is eight teams and a platform they must choose to adopt, not one team's pipeline. Communication switches to Slack — Minh thinks out loud and replies fast. The senior colleague register flips back to Marco's warm war stories. And mechanism selection becomes a deliberate decision: you have used memory, a skill, and two hooks across earlier projects; here you choose which one encodes which rule.

The hard part: a canary that reports success while the service degrades is the most dangerous deployment failure there is, because the system believes it is healthy. The only proof the integration is real is breaking the metric connection on purpose and confirming the rollback fails to fire. A shared pipeline eight teams cannot understand, get feedback from, or get help with will not be adopted no matter how well it is engineered.

Tools

• Git / GitHub — GitHub Actions is the shared CI/CD substrate. The reusable workflow you build is the framework eight teams use.
• Terraform — small applied footprint: the budget alarm and the sandbox-scale canary demonstration stack.
• AWS CLI — the canary mechanism (Lambda alias weighted traffic shifting, CodeDeploy's built-in automatic rollback), CloudWatch for the canary signal, and the orphan scan at teardown.
• AWS Budgets — the budget guardrail, provisioned first.
• The inherited AI toolkit — CLAUDE.md memory, the security-audit skill, the checkov and Infracost hooks, all carried forward. This is the first project where which mechanism encodes which rule is your decision.

Materials

In the project zip:

• Minh's Slack thread (minh-slack-thread.md) — the engagement-opening message. What it does not contain is the discovery agenda; the load-bearing constraints surface only when you probe.
• CLAUDE.md — the project governance file, carried forward in shape from last time with ĂnNhanh substance and two TODO markers you resolve during the engagement.
• AI-mechanism reference (ai-mechanism-reference.md) — a one-page framing of the memory / skill / hook trade-off. No answers; it frames the decision you make later.
• The inherited AI toolkit (CLAUDE.md memory, the security-audit skill, the checkov and Infracost hooks).

There is no architecture template, no canary recipe, and no mechanism-selection checklist. The architecture comes from the conversation. The budget-alarm-first habit and the orphan-scan teardown discipline carry forward unchanged.