Skip to content

DevOps Technical Debt

DevOps Choices We Should Revisit as We Grow

Section titled “DevOps Choices We Should Revisit as We Grow”

Aka - where the skeletons are buried and when should we take care of them?

  • Protection against accidental deletion: We should up the protection on accidental deletion of a fly app by any dev.

    As of 2024-03-01, there are clunky ways to do it (see threads), and fly is considering a better feature.

    When to tackle it? Tough one. Arbitrary target - when we hit 10 devs in the team?

  • Alternative: Production organization: The other alternative is to create a new organization for production, with limited access. This might be quite painless.

  • Use --json where possible when calling fly for more parseable output
  • S3 robustness with boto: E.g. if the copy command fails, are we guaranteed that an exception is thrown

We have Dashlane individual, not Dashlane Business. Might be needed for SOC-2 (SSO, easier offboarding).

  • Similar to fly, our current developer plan gives too many folks access to too many secrets. Upgrading to Team ($18/m/u) would give us per user access control.

  • We could also create a second doppler account for production with limited access, and create a script to sync keys across environments. May not lose much.

  • We may also want to tackle removing non-secrets from Doppler and baking them into fly configs (the env section) instead.

  • Another approach would be to switch to using doppler API from the apps to retrieve the environment rather than syncing doppler to fly.

  • 2024-07-24: Enlightn is run alongside PHPStan. It might make sense to get rid of PHPStan once we’re comfortable with Enlightn, see comment here.
  • We’ve briefly played with HyperDX, but then the integration broke and nobody really cared. On 2024-03-20 we decided to pull the plug for now, but it might become more relevant later if Sentry doesn’t give us all we need. See slack thread.