7 ms·

In many (most?) cases people have a single production environment. If you have multiple versions in the wild to support, there's nothing stopping you from supp

In many (most?) cases people have a single production environment. If you have multiple versions in the wild to support, there's nothing stopping you from supporting multiple upgrade paths, or even continuing to chain migration files, if you want to. Moving data about is always going to be a manual process. This approach just helps you test it better.

jayd16 8y ago
I would say this is a pretty limited view. If you're working on a large team with many non production environments, this style is far more cumbersome than the upgrade chain method. If we're talking about deployed sqlite dbs running on client machines, expecting an upgrade to be a manual process is simply not acceptable.
- djrobstep 8y ago
  What makes it more cumbersome?
  - jayd16 8y ago
    If I'm understanding correctly, the suggestion is to run the migration by hand and handle issues as they arise. Not nearly as nice as an automated migration.
    - djrobstep 8y ago
      The talk is more about creation migration scripts than deploying them, but definitely not suggesting doing anything by hand. The idea is to ensure correctness so you can automate the deployments with confidence.
mdonahoe 8y ago
What about apps running on users’ devices, with their own internal databases for local storage? When a user on random old version finally updates their app to latest, that latest code better be able to handle a migration correctly.
gpm 8y ago
Backups...
recursive 8y ago
You just got done telling me that migrations are bad, but also the solution to some non-trivial deployment scenario is to just continue using migrations? > Moving data about is always going to be a manual process. No, it's not always.
- djrobstep 8y ago
  Did you even read it? No idea where you got "migrations are bad" from. If moving data around within a migration isn't always a manual process, please show me the tool which automatically generates the correct statements.
  - recursive 8y ago
    I don't believe a tool can always generate the correct statements. But I do believe those same statements can be used on all deployments, which I consider automation.
twic 8y ago
> In many (most?) cases people have a single production environment. No idea why this was downvoted, because this is a key truth. You need to be able to migrate the production database to the latest version without losing any data. You need to be able to replace any non-production database with the same schema as production. Ideally, with a (sanitised, subsetted, etc) copy of its data. You don't need to be able to do anything else.
- akx 8y ago
  You're only thinking about SaaSy things there. What about on-premises or just open-source software, where you any number of any version of your software may be installed around the universe, and those users need to upgrade to a newer version?
- simonw 8y ago
  See my comment here about organizations with many engineers and teams: https://news.ycombinator.com/item?id=19289778 https://news.ycombinator.com/item?id=19289778
simonw 8y ago
I don't buy this at all. It may be true for projects with only a single developer, but consider environments with a larger team. First, every developer has a development environment. If someone goes on holiday for a few weeks they will come back to a personal environment that's likely several steps behind everyone else. Smart engineering orgs have one or (hopefully) more QA environments which differ from production by design - they're where you preview and test upcoming features that may involve schema changes. At a certain scale individual teams may have their own dedicated QA environments, for testing in-development features without disrupting the work of other teams. Then there are environments for running integration tests, hooking up to CI systems, load testing etc. There may be only one production environment but there could be dozens or even hundreds of other environments that need to be able to reliably apply migrations up to a specific point. The Django approach to migrations handles this really well.
- djrobstep 8y ago
  ? None of those are production environments.
  - simonw 8y ago
    They're "production" in as much as they need to work. They still need to have migrations applied to them in an automated and repeatable way.
    - djrobstep 8y ago
      "An environment that needs to work" is not what "production environment" means.

jayd16 8y ago

I would say this is a pretty limited view. If you're working on a large team with many non production environments, this style is far more cumbersome than the upgrade chain method. If we're talking about deployed sqlite dbs running on client machines, expecting an upgrade to be a manual process is simply not acceptable.

djrobstep 8y ago
What makes it more cumbersome?
- jayd16 8y ago
  If I'm understanding correctly, the suggestion is to run the migration by hand and handle issues as they arise. Not nearly as nice as an automated migration.
  - djrobstep 8y ago
    The talk is more about creation migration scripts than deploying them, but definitely not suggesting doing anything by hand. The idea is to ensure correctness so you can automate the deployments with confidence.

mdonahoe 8y ago

What about apps running on users’ devices, with their own internal databases for local storage? When a user on random old version finally updates their app to latest, that latest code better be able to handle a migration correctly.

gpm 8y ago

Backups...

recursive 8y ago

You just got done telling me that migrations are bad, but also the solution to some non-trivial deployment scenario is to just continue using migrations? > Moving data about is always going to be a manual process. No, it's not always.

djrobstep 8y ago
Did you even read it? No idea where you got "migrations are bad" from. If moving data around within a migration isn't always a manual process, please show me the tool which automatically generates the correct statements.
- recursive 8y ago
  I don't believe a tool can always generate the correct statements. But I do believe those same statements can be used on all deployments, which I consider automation.

twic 8y ago

> In many (most?) cases people have a single production environment. No idea why this was downvoted, because this is a key truth. You need to be able to migrate the production database to the latest version without losing any data. You need to be able to replace any non-production database with the same schema as production. Ideally, with a (sanitised, subsetted, etc) copy of its data. You don't need to be able to do anything else.

akx 8y ago
You're only thinking about SaaSy things there. What about on-premises or just open-source software, where you any number of any version of your software may be installed around the universe, and those users need to upgrade to a newer version?
simonw 8y ago
See my comment here about organizations with many engineers and teams: https://news.ycombinator.com/item?id=19289778 https://news.ycombinator.com/item?id=19289778

simonw 8y ago

I don't buy this at all. It may be true for projects with only a single developer, but consider environments with a larger team. First, every developer has a development environment. If someone goes on holiday for a few weeks they will come back to a personal environment that's likely several steps behind everyone else. Smart engineering orgs have one or (hopefully) more QA environments which differ from production by design - they're where you preview and test upcoming features that may involve schema changes. At a certain scale individual teams may have their own dedicated QA environments, for testing in-development features without disrupting the work of other teams. Then there are environments for running integration tests, hooking up to CI systems, load testing etc. There may be only one production environment but there could be dozens or even hundreds of other environments that need to be able to reliably apply migrations up to a specific point. The Django approach to migrations handles this really well.

djrobstep 8y ago
? None of those are production environments.
- simonw 8y ago
  They're "production" in as much as they need to work. They still need to have migrations applied to them in an automated and repeatable way.
  - djrobstep 8y ago
    "An environment that needs to work" is not what "production environment" means.