Every project at AptixLabs lives in GitHub with branch-protection rules and required CI checks. The studio prefers small, frequent deploys over big releases — it ships multiple times a day on active projects.
What CI runs
- TypeScript type-checking with strict mode
- ESLint with the project's ruleset
- Vitest unit tests for the logic layer
- A production build to catch any runtime config mistakes
- Firestore security-rule tests via the official Firebase emulator
Web deploys
Marketing sites and the coach portal deploy to Firebase Hosting through a GitHub Actions workflow that promotes the build only after CI passes on the main branch. Preview channels spin up for every PR — a partner can see a working build before merge.
Mobile deploys
The mobile apps deploy through Fastlane and EAS Build to App Store Connect and Google Play. There's a manual gate before release-to-production but automatic uploads to TestFlight and internal-testing tracks. The same commit can ship to web in five minutes and mobile within an hour after store review.
Secrets
Secrets live in Google Secret Manager and are fetched at runtime — never baked into the build. CI uses workload-identity federation rather than long-lived service-account keys.
Why small deploys are a safety feature
A big release is a big blast radius. When twenty changes ship together and something breaks, you are bisecting twenty suspects under pressure. When one change ships at a time, the suspect is obvious and the rollback is trivial. Shipping multiple times a day is not recklessness — it is the opposite. Small, frequent, reversible changes are how you move fast without the fear, and the CI gate is what makes each one safe to send.
What runs before anything reaches a user
- Type-check in strict mode — a whole class of runtime bugs caught before merge
- Lint + unit tests on the logic layer
- A production build, so a broken config fails in CI, not in front of a user
- Firestore security-rule tests in the emulator — a bad rule can never reach production
- Preview deploy per pull request, so a partner sees the change before it merges