3 ms·

Okay, so you changed the DB schema in your 'dev' environment to add a column. 1. In what manner/format do you define or commit the change to VCS so it is in sy

Okay, so you changed the DB schema in your 'dev' environment to add a column. 1. In what manner/format do you define or commit the change to VCS so it is in sync with the corresponding code change (that uses the new column)? 2. What happens when a teammate comes to deploy that schema change to production? 3. What happens when we need to roll back production to some previous commit? The need to rollback may/may-not relate to the schema change (not suggesting you 'got it wrong'). If you can answer 1, 2, 3 by some convention ... you've created a migration system that should probably be codified.

tinix 9y ago
1. Change model code to add the new field, test, and commit it to version control. Then it's merged to staging, where it's tested in a production-like environment with a recent production data snapshot. After that's approved, it goes to master/production servers. 2. git pull then restart some wsgi/worker processes 3. git checkout to desired revision and restart some wsgi/worker processes It's perfectly fine to have models comprised of only a subset of the data they interact with. The models do not have to reflect all fields that exist in the database. The models only reflect information that is necessary for the application in which said models are used. Basically, if you clobber your database, no amount of migration tooling or process will help you. Ever. It will just get in the way, to be honest, and will prevent you from doing things properly in the first place.
- allover 9y ago
  You missed the point of all those questions (e.g. in 2 you don't mention how the schema change gets applied to the prod database). Unfortunately I'm frankly out of patience explaining any further, so we'll have to leave it there.
  - tinix 9y ago
    There is no schema change, that's the point. You just don't get it... but that's okay.
    - allover 9y ago
      Okay you didn't read the question then. > [...] you changed the DB schema in your 'dev' environment to add a column [...] The 'point' is we are adding a column, and we want a sane workflow that works in a team from dev through to production.

tinix 9y ago

1. Change model code to add the new field, test, and commit it to version control. Then it's merged to staging, where it's tested in a production-like environment with a recent production data snapshot. After that's approved, it goes to master/production servers. 2. git pull then restart some wsgi/worker processes 3. git checkout to desired revision and restart some wsgi/worker processes It's perfectly fine to have models comprised of only a subset of the data they interact with. The models do not have to reflect all fields that exist in the database. The models only reflect information that is necessary for the application in which said models are used. Basically, if you clobber your database, no amount of migration tooling or process will help you. Ever. It will just get in the way, to be honest, and will prevent you from doing things properly in the first place.

allover 9y ago
You missed the point of all those questions (e.g. in 2 you don't mention how the schema change gets applied to the prod database). Unfortunately I'm frankly out of patience explaining any further, so we'll have to leave it there.
- tinix 9y ago
  There is no schema change, that's the point. You just don't get it... but that's okay.
  - allover 9y ago
    Okay you didn't read the question then. > [...] you changed the DB schema in your 'dev' environment to add a column [...] The 'point' is we are adding a column, and we want a sane workflow that works in a team from dev through to production.