Here's how the CI/CD flow works for each scenario:
Current CI/CD Architecture
familiarise_web/prisma/schema.prisma (source of truth)
│
├── copied to ──→ backend/prisma/schema.prisma (was a symlink, now a
real file)
│
└── used by ──→ Dockerfile during Railway build
Scenario 1: You update the Prisma schema (in familiarise_web)
This is a manual step right now:
1. You edit familiarise_web/prisma/schema.prisma
2. You must manually copy it to the mobile repo:
cp ~/Desktop/familiarise_web/prisma/schema.prisma
~/Desktop/familiarise_mobile/backend/prisma/schema.prisma
3. Locally regenerate: ./scripts/regenerate-build.sh --prisma
4. Commit & push to dev, merge to prod
5. The backend-deploy.yml workflow triggers on push to prod (with backend/** path
filter)
6. Railway builds the Docker image which regenerates everything from scratch:
- prisma_flutter_connector:generate → lib/generated/
- build_runner → freezed/json codegen
- dart_frog build → server bundle
- dart compile exe → AOT binary
7. Railway deploys the new binary
Key point: The Dockerfile regenerates all generated code during build, so even
though lib/generated/ is gitignored, it always builds fresh from the schema file
that IS committed.
Scenario 2: You update code in familiarise_mobile (no schema change)
1. You push changes to dev
2. Create PR → flutter-ci.yml runs:
- analyze job: lint + tests (Flutter frontend)
- test-backend job: dart analyze + dart test (backend)
3. Merge to dev → CI runs again
4. Merge dev → prod → backend-deploy.yml triggers:
- Tests the backend
- Deploys to Railway via railway up
- Health check verification
Scenario 3: You push to a hotfix/* branch
1. flutter-ci.yml detects the hotfix/* branch
2. The shorebird-patch job runs automatically
3. Shorebird patches both Android and iOS
4. Users get the fix on next app launch — no store review needed
Scenario 4: You tag a release (v1.0.0)
1. flutter-ci.yml detects the tag
2. Runs: analyze → build Android AAB → build iOS IPA → deploy to Play Store + App
Store
3. After store deploys, shorebird-release job registers the release with
Shorebird
4. Future hotfixes can then patch against this release
The flow visually:
Push to dev → CI tests only (no deploy)
Merge to prod → CI tests + Railway auto-deploy (backend)
Tag v*.*.* → CI tests + store builds + store deploy + Shorebird release
Push to hotfix/* → Shorebird patch (OTA, no store review)
Manual dispatch → Shorebird patch (same as hotfix)
What's NOT automated yet:
- Schema sync from web → mobile: manual cp required
- GitHub Secrets: all need to be added manually (currently zero exist)
- prod branch: needs to be created after merging the current PR
Press Space, Enter, or Escape to dismiss
Here's how the CI/CD flow works for each scenario:
Press Space, Enter, or Escape to dismiss