Skip to content

Development Practices

Engineering workflows, repository strategy, and development processes for Silver Frog.

Last Updated: January 2026 Status: Draft

Principles

  1. Ship small, ship often - Small changes reduce risk and speed up feedback
  2. Main is always deployable - Never break the main branch
  3. Automate everything - CI/CD, testing, deployments
  4. Collective ownership - Everyone can work on any part of the codebase

Repository Strategy

Monorepo

All application code lives in a single repository.

silverfrog/
├── apps/
│   ├── casino/               # Elixir Phoenix API
│   ├── sportsbook/           # Elixir Phoenix API
│   ├── backoffice/           # Internal admin tools
│   └── shared/               # Shared Elixir libraries
├── tools/
│   ├── cli/                  # Go CLI tools
│   └── scripts/              # Automation scripts
├── infra/
│   ├── terraform/            # Infrastructure as code
│   └── kubernetes/           # Helm charts, ArgoCD apps
├── docs/                     # Documentation
└── .github/
    └── workflows/            # CI/CD pipelines

Why monorepo:

  • Atomic changes across multiple apps
  • Shared code without package publishing
  • Single CI/CD pipeline
  • Easier refactoring
  • Unified versioning and tooling

Tooling:

  • Build system: Native per language (Mix with Workspace for Elixir, Go toolchain for Go)
  • Affected detection: Only build/test what changed
  • Caching: Leverage CI cache for dependencies

Branching Strategy

Trunk-Based Development

Following trunkbaseddevelopment.com guidelines.

All developers collaborate on main (trunk). The main branch is production.

Rules:

  1. Commit frequently - Multiple times a day
  2. Small commits - Each commit should be reviewable in minutes
  3. Feature flags - Hide incomplete features
  4. No long-lived branches - Branches merge within hours to 1-2 days max

Short-Lived Feature Branches

For code review, use short-lived branches. Each branch gets an automatic preview environment.

Branch lifetime: Hours to 1-2 days maximum.

Preview environments: ArgoCD ApplicationSets create ephemeral environments per PR for review and testing. Destroyed automatically on merge.

Code Review

Pull Request Guidelines

  • Small PRs - Aim for <600 lines changed
  • Self-review first - Review your own diff before requesting
  • One approval required - For most changes
  • Two approvals - For critical paths (payments, auth, infra)
  • Tests - Majority of PRs should contain tests, exeption cases are infra code, library updates and configuration changes.

Review Checklist

  • Code is clear and readable
  • Tests cover the change
  • No security concerns
  • No breaking changes (or properly flagged)
  • Documentation updated if needed

Feature Flags

Hide incomplete or risky features behind flags instead of branches.

# In code
if FeatureFlags.enabled?(:new_casino_flow, user) do
  # New implementation
else
  # Current implementation
end

Flag lifecycle:

  1. Create flag - Before starting work
  2. Develop behind flag - Ship to main, hidden from users
  3. Test in preview - Enable in PR preview environment
  4. Full rollout - Enable for everyone after testing and deploying to production
  5. Remove flag - Clean up old code path

Implementation: Custom DB-backed feature flags. Simple table with flag name, enabled state, and optional user/percentage targeting.

CI/CD Pipeline

Continuous Integration

Every commit triggers CI, which will:

  • Compile check
  • Lint
  • Tests
  • Preview env

Continuous Deployment

Trigger Action
PR opened Deploy to preview environment
PR merged Deploy to production, destroy preview
Tag release Tag production deployment

Testing Strategy

Level Scope Speed Coverage Target
Unit Functions, modules Fast High
Integration API endpoints, database Medium Medium
E2E Critical user flows Slow Low (happy paths)

Testing principles:

  • Test behavior, not implementation
  • Fast tests run on every commit
  • Slow tests run on main branch only
  • No flaky tests in CI

Release Process

Release Cadence

Continuous deployment - every merge to main deploys to production.

Hotfix Process

  1. Create short-lived branch from main
  2. Fix issue, open PR with preview environment
  3. Test on preview, merge to main
  4. Automatic deployment to production
  5. No bypassing CI/CD