CI/CD
AI projects change frequently. Manual deployment is error-prone. CI/CD ships with confidence.
An assembly line checkpoint — every product is inspected and packaged automatically. Defects never reach customers.
Visual Workflows
Start here — study each diagram, then use + / − to zoom if needed.
Overview
Scroll inside the frame · use + / − to zoom
Scroll inside the frame · use + / − to zoom
Key Takeaways
- 1.CI/CD automates testing, building, and deploying your app — every code change is validated before reaching production.
- 2.CI runs tests on every push/PR.
- 3.CD deploys on merge to main.
- 4.GitHub Actions is the most common tool.
- 5.Secrets go in GitHub Secrets, never in workflow files.
Real Example
Scenario
You push a new RAG retriever to a feature branch and want it tested before production.
What you would do
GitHub Actions runs pytest on the PR, builds the Docker image on merge to main, deploys to staging, runs a smoke test, then promotes to production.
Practice Task
Create .github/workflows/ci.yml that runs on push and executes pytest (or echo "CI would run here" if you have no tests yet). Push to GitHub and check the Actions tab for the run result.
Commands
Commands to Remember
git push # trigger the CI pipeline on remotegh workflow run deploy.yml # manually trigger a GitHub Actions workflowgh run list # view recent CI/CD runsgh run view <id> --log # see full logs for a specific run
Cheat Sheet
Quick recap
quick ref- •CI runs on every push/PR — lint, test, build Docker image
- •CD deploys on merge to main — staging then production
- •GitHub Actions is the most common CI/CD tool
- •Never put API keys in workflow YAML — use GitHub Secrets
- •Run expensive LLM evals on schedule, not every PR
- •Pipeline: test → build → deploy · smoke test before production
Common Mistakes
- ✕Secrets in workflow YAML
- ✕Expensive LLM evals on every PR
- ✕No staging environment