SmartStore AI — Phase 11 Implementation Guide

CI/CD & MVP Deployment

What got built

.github/workflows/ci.yml    — test -> eval -> deploy pipeline
render.yaml                  — Render Blueprint for the MVP deployment stage

Key design decisions

Three separate jobs (test, eval, deploy), not one. eval depends on test; deploy depends on both. This matters specifically because eval needs a real Anthropic API key and real ingested data, while test doesn't (every test in this entire bootcamp-built suite uses fake clients/embedders). Splitting them means a temporarily expired or rate-limited API key blocks deploys without blocking the much faster, cheaper unit/integration suite from running and reporting on every PR.

The eval job's threshold check (< 0.9) actually fails the pipeline, via raise SystemExit, not just prints a warning. This is Volume 4, Chapter 7's central point: an eval regression should be exactly as blocking as a failing unit test, not an FYI someone might ignore.

The RLS app role (Phase 6) gets created fresh in CI, via the same SQL as Phase 6's guide, because CI's Postgres service container starts empty every run — this is a real, necessary step the workflow would silently fail without, not boilerplate.

render.yaml deliberately leaves DATABASE_URL_APP and QDRANT_URL as sync: false (manually set in Render's dashboard) rather than fully automated. Render doesn't know about Phase 6's restricted-role convention or which Qdrant hosting option you picked — pretending otherwise in the Blueprint would just produce a confusing failure at deploy time instead of an honest manual step.

Verified

The workflow YAML and Render Blueprint YAML were both parsed directly with Python's yaml library to confirm they're syntactically valid and structured with the dependency chain intended (test → eval → deploy) — confirmed directly, not assumed from reading the file.

What wasn't, and can't be, verified here: an actual GitHub Actions run (needs a real repo + secrets) and an actual Render deployment (needs a real Render account + the manual setup steps noted in render.yaml's comments). Both are genuinely external infrastructure this sandbox has no access to — the same honest limitation as every live-API step in this guide.

Setting this up for real

1. Push this repo to GitHub
2. Add repo secrets: ANTHROPIC_API_KEY, OPENAI_API_KEY, RENDER_DEPLOY_HOOK_URL (Settings → Secrets and variables → Actions)
3. Connect the repo in Render's dashboard via "New +" → "Blueprint" — it should detect render.yaml
4. Manually create the smartstore_app role against Render's managed Postgres (same SQL as Phase 6), and paste both connection strings into Render's dashboard
5. Set up Qdrant — either Qdrant Cloud's free tier, or a second Render private service running the qdrant/qdrant image

What's next

Phase 12 — Production Hardening & AWS moves this from Render to the real production target: ECS Fargate, RDS, ElastiCache, S3, and Secrets Manager.