5
lotd
226d

How is it, that features goes thru the entire mill of dev, staging, preview.
Then when deployed to production, things blow up..
Turns out, columns are nullable only in production DB and of course, those happen to be null in there.

If I had a dime for every time I’ve seen shit like this…

(╯°□°)╯︵ ┻━┻

Comments
  • 4
    I forgot the best part, it’s not even my code that blew up.
    It just happen to coincide with my deployment, so I got flagged and assigned for production outage 😂
  • 2
    Schema compare?
  • 2
    @donkulator don’t have access to anything in production.
    But suggested to mgmt that we should gather differences from prod and reflect down.
  • 3
    obviously your staging environment is borked up, if it doesn't reflect the exact database structure of production.

    regularly making sure that stage is up to spec is an important step that shouldn't be neglected.
  • 5
    @tosensei agree. The problem seems to stem from direct updates in prod db. At least that’s what I’m told lol.
    Narrows the list of suspects down a lot since it’s a handful that has access 😂
  • 2
    ah nice the classic hot fix in prod only, undocumented, and never reflected in the rest of the dev / staging stack

    🤡🤡🤡
  • 1
    Makes me feel so happy I work on an application that doesn’t interface with a database directly (we go through an API managed by another team, this has greatly reduced database issues) and don’t do significant writes other than per-user - cause we can have a preprod environment which runs unshipped code + the prod database

    And even then there’s been unexpected issues due to settings unique to prod (such CDN/Edge Server config - like bot prevention)
Add Comment