Skip to main content

Dev Ops

Handling Incidents (on call)

Roles:

  • Lead: asks questions and keeps the investigation moving (but doesn’t actually investigate)
    • As the issue evolves, can suggest role changes - e.g. if a new main investigator makes sense
  • Scribe: realtime investigation updates in the incident channel (for channel members)
    • really helpful for people who arrive on the call late or have to hop off and return later
  • Communicator: wider, non-technical updates for users not involved in the incident
  • Main investigator: drills into technical hunting + debugging

Links:

## Authorization

Hosting

App Hosting:

  • 📖 Netlify • Develop & deploy the best web experiences in record time
  • 📖 Render • Cloud Application Hosting for Developers
  • CloudFlare Workers:
    • Workers • Cloudflare 🛠️

      CloudFlare Workers lets developers deploy serverless code written in JavaScript, Rust, C and C++ to Cloudflare’s edge, closer to the end user. This enables lower latency and better performance for your users. Workers is built on the same technology that powers Cloudflare’s global network, so you can deploy a sub-30ms function to more than 200 cities in less than 30 seconds.

    • 🌲 cloudflare worker link tree • Walks through setting up a worker
    • Cloudflare Workers • Cloudflare Workers docs
    • Adding Caching to a Cloudflare Worker • How to add basic caching to a Cloudflare Worker serverless worker.

Continuous Integration

Dependency Management

Continuous Delivery

Feature Flags

  • LaunchDarkly has no free tier. Is there a solid free alternative for open source users? A reliable way to create this myself (e.g. with a “Feature Flags” Notion DB)?
  • can set the flag to a different value in each environment
    • e.g. off in prod, on in local dev
  • why flag?
    • avoid long-lived feature branches that grow large
    • support continuous delivery of small changes even if they are pieces of incomplete features that won’t be shown yet
    • can deploy code without releasing the feature (decouples those two things)
  • flag/toggle categories (see Feature Toggles (aka Feature Flags):
    • release flags (for deploying incomplete/new features via CD)
    • experiment flags (for A/B tests)
    • ops flags (to rollback in case of perf issues)
    • permissioning flags (to control who sees a feature)
  • how to implement?
    • inversion of control — instead of calling the flag provider inside the logic, pass in a boolean result from outside the function (way easier to test)
    • place flag at UI level whenever possible rather than sprinkling throughout the logic
      • e.g. hide a user input so you don’t have to disable the logic it triggers
    • add a “flag removal” task whenever one is added
    • consider setting an expiry date that would cause tests to fail
  • how to test
    • test with current prod config + any flags planned to turn on now both off and on
    • also test with all flags on and all flags off

Inbox