0

We use Sequelize. This is how we do database structure changes:

- I create/change a model in Sequelize, and let it change my local database, then I do work on that
- I push the new code to a remote branch
- my boss/CTO/lead dev then manually creates/changes the relevant table(s) in our staging database
- I finally merge the branch I originally developed into the remote branch
- boss checks that everything is working
- at last, boss does the same process of modifying/creating tables in production database
- finally, staging code is merged into main

So right now:
- I'm changing a feature, forgot I was editing in the main branch
- go ahead and create a remote branch for it, pull locally, checkout local version of newly created branch
- try to run code
- oops, there's a missing column in one of my local database tables
- ask for boss for SQL script that will create the missing column and potentially add more data or whatever
- waiting for boss to respond

H-how can we improve this process? Boss has talked about us moving to use migrations but we never ended up doing it. I don't know much about migrations either. This is gonna suck so hard.

Comments
  • 1
    You and boss really need to consider different sets of data and migrations.

    Seed (fake) data for dev/testing environment, migrations for reproducability of database structure without reiterating it. That one migration script for column is the perfect example. Each rename, type change, initial set of records - it all commits to keeping all databases up to date.
  • 2
    Sudden urge to modify all existing records in the table to conform to a new application logic or types? One migration away.
  • 1
    Same issue here. Migrations are required really, but I have like 40 things to do before I even get there.
Add Comment