Automate database migrations

[eatyourgreens]

Database changes are currently made by hand on the running database (see #206.) Alembic looks like a good choice for managing migrations with SQLAlchemy.
https://alembic.sqlalchemy.org/en/latest/

[tomalrussell]

cc @mz8i for infra-risk-vis/backend - perhaps one of you could write the patch for both?

[mz8i]

It seems that there is a lot of overlapping work to be done on the API for both projects (this issue, #126 , nismod/infra-risk-vis#188 ) - is this a good moment to consider having the backend API as a shared project?
The challenge I think is that while the API code (especially for the features/attributes endpoints) has stayed fairly the same, the way it's deployed and ran has changed completely (would you say that's correct @tomalrussell ?).

It's probably worth adding that for the infra-ris-vis backend, we have the auto-generated https://github.com/nismod/irv-api-client-ts which makes it a bit easier to use from the frontend (in case irv-jamaica was to be migrated to use the shared API)

[eatyourgreens]

Since irv-jamaica is deployed via docker compose, I don't think it would be a big change to switch the image used by the backend service. The client is generated from http://localhost:8888/openapi.json, running the backend locally, so that shouldn't be a problem either, assuming that the endpoints and response types are more-or-less the same.

[tomalrussell]

I think deployment is now pretty similar between the two.

The main difference is that infra-risk-vis/containers/backend has the terracotta tile service bundled in; this could be pulled out and kept in infra-risk-vis if we factor out an irv-backend (I don't think there's any cross-dependency between serving the raster tiles API and the features API.)