In the creation of staging lite apps, we need to store the id.
Alternative Consideration:
Achieving quickie without this migration
We dont really need this column, because we could derive this by just keeping this within the staging url. (the staging url actually has the app id here). The reason for adding this is because of
the unknowns of what if we need a rollback for quickie (esp for privatisation), the info is lost.
speed of dev. I intend to decouple releasing of quickie from actually laying the infra work needed for quickie (including private sites. Rather than maintaining a mental model of 'oh some amplify github repos have staging branches and some dont, we make ALL sites have a staging github repo, but it will not be used (at least in the case of private repos) until next year.
TLDR; this helps lay the groundwork for quicker iterations + quicker rollback.
I do keep in mind that if quickie + its intergrations are stable, actually dont really need this column, we can throw away this column then.
Making this column non-nullable
While it does not make sense for an amplity app in our repo not to have a staging lite app, we do not codify this at the db level as making repos have staging-lite branch + creating amplify apps are not instant, and have to prob be done over the weekend (sed). To allow for that time delay, they are allowed to be null. This could be changed in the future.
Deployment notes
Migration for Staging + Production are already DONE.
Problem
In the creation of staging lite apps, we need to store the id.
Alternative Consideration:
Achieving quickie without this migration
We dont really need this column, because we could derive this by just keeping this within the staging url. (the staging url actually has the app id here). The reason for adding this is because of
TLDR; this helps lay the groundwork for quicker iterations + quicker rollback.
I do keep in mind that if quickie + its intergrations are stable, actually dont really need this column, we can throw away this column then.
Making this column non-nullable
While it does not make sense for an amplity app in our repo not to have a staging lite app, we do not codify this at the db level as making repos have staging-lite branch + creating amplify apps are not instant, and have to prob be done over the weekend (sed). To allow for that time delay, they are allowed to be null. This could be changed in the future.
Deployment notes
Migration for Staging + Production are already DONE.