Skip to main content

​
Overview

Tuteliq follows a structured development lifecycle to ensure all code changes are reviewed, tested, and safely deployed to production. This document describes the end-to-end process from development to production release.

​
Branch Strategy

Tuteliq uses a trunk-based development model with short-lived feature branches:
BranchPurposeProtection
mainProduction-ready codeProtected — no direct pushes, requires PR
feat/*New featuresDeveloper branch
fix/*Bug fixesDeveloper branch
hotfix/*Critical production fixesExpedited review process

​
Code Merge Process

1

Feature Branch

All changes begin on a dedicated branch created from main. Branch naming follows the convention feat/description, fix/description, or hotfix/description.
git checkout -b feat/add-new-detection-endpoint
2

Development & Local Testing

Developers write code and run the full test suite locally before pushing:
  • Unit tests
  • Integration tests
  • Type checking (TypeScript strict mode, mypy, swiftformat, dart analyze)
  • Linting (ESLint, Prettier, SwiftFormat, Ruff)
All code must pass local CI checks before a pull request is created.
3

Pull Request

A pull request is opened against main with:
  • Clear description of the change and its purpose
  • Link to the relevant issue or task
  • Test plan describing how the change was verified
  • Screenshots or examples for UI or API response changes
4

Automated CI Checks

Every pull request triggers automated CI pipelines that must pass before merge:
  • Build — Compilation and type checking across all supported targets
  • Test — Full unit and integration test suite
  • Lint — Code style and formatting enforcement
  • Security — Dependency vulnerability scanning (Dependabot / GitHub Advisory Database)
Pull requests cannot be merged if any CI check fails.
5

Code Review

All pull requests require at least one approving review from a team member before merge. Reviewers evaluate:
  • Correctness and logic
  • Security implications (injection, auth bypass, data exposure)
  • Performance impact
  • Test coverage for new or changed functionality
  • API contract and backward compatibility
  • Adherence to coding standards and project conventions
6

Merge to Main

After CI passes and review is approved, the pull request is merged into main using squash merge to maintain a clean commit history. The feature branch is automatically deleted after merge.
7

Production Deployment

Merges to main trigger automatic deployment to production via the CI/CD pipeline:
  • API — Deployed to Google Cloud Run with zero-downtime rolling updates
  • SDKs — Published to respective package registries (npm, PyPI, pub.dev, Maven Central, NuGet, Swift Package Index) on tagged releases
  • Documentation — Auto-deployed via Mintlify on push to main
Deployments are monitored for errors and latency regressions. Automatic rollback is triggered if health checks fail.

​
Hotfix Process

For critical production issues:
  1. A hotfix/* branch is created directly from main
  2. The fix is implemented with targeted tests
  3. An expedited code review is performed
  4. The hotfix is merged and deployed immediately
  5. A post-incident review is conducted within 24 hours

​
Security Controls

ControlImplementation
Branch protectionmain requires PR, passing CI, and approving review
Dependency scanningAutomated via GitHub Dependabot with weekly scans
Secret detectionPre-commit hooks and CI checks prevent secrets from being committed
Access controlRepository access follows least-privilege principle
Audit trailAll changes tracked via Git history and GitHub audit log
Signed releasesSDK releases are tagged and published through CI with verified provenance

​
Environment Promotion

Code progresses through environments before reaching production:
EnvironmentPurposeTrigger
DevelopmentLocal development and testingDeveloper machine
StagingPre-production validationPush to main (pre-deploy step)
ProductionLive customer trafficAutomatic after staging health checks pass
All environments use isolated infrastructure, separate API keys, and independent databases. Production credentials are never accessible from development or staging.

​
Monitoring & Rollback

  • Health checks — Automated HTTP health probes on every deployment
  • Error tracking — Real-time error monitoring with alerting
  • Latency monitoring — P50/P95/P99 latency tracked per endpoint
  • Automatic rollback — Cloud Run reverts to the previous revision if the new deployment fails health checks
  • Manual rollback — Any team member can trigger an immediate rollback via the deployment dashboard

​
Questions

For questions about our development process or to request additional documentation, contact security@tuteliq.ai.