You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A recent snapshot of the original production VegBank database should be up & running in a currently supported version of Postgres deployed to the Kubernetes dev cluster, in a manner that supports future code-driven database schema modifications as needed. Moreover, the process for achieving this outcome should be fully reproducible and applicable both in a fresh dev environment and in our production K8s environment, the latter being critical to ensuring we are able to deploy VegBank to production as part of our final rollout.
Details
The objective here is twofold:
Develop a robust end-to-end process for achieving our project deliverable of having the VegBank DB running on a current version of Postgres on Kubernetes. As a bonus outcome, the setup should include a database migration framework for robustly defining, applying, and logging future schema changes.
Get an instance of the current VegBank DB running in our dev K8s environment for use in new REST API development and testing.
Assume that the DB contents will be provided as a full dump file from the original production database, and for any & all future fresh deployments, a then-current version of this dump file will likewise be provided.
Acceptance criteria
K8s deployment and configuration should done via a Helm chart
The database itself should, of course, be persistent across pods restarts
Any configuration details that may differ in our future Production K8s deployment should be appropriately handled in the Helm chart, with documentation
Creation of the new VegBank DB instance can be triggered manually, but all schema instructions should be fully described in and driven by code
Similarly, any subsequent schema modifications required to complete the data load can be triggered manually, but should be fully described in and driven by code -- in particular, using Flyway
The end-to-end steps for achieving this outcome should be automated where feasible, and otherwise clearly and accurately documented in a manner that can be easily followed to achieve the same outcome in a fresh environment
Outcome
A recent snapshot of the original production VegBank database should be up & running in a currently supported version of Postgres deployed to the Kubernetes dev cluster, in a manner that supports future code-driven database schema modifications as needed. Moreover, the process for achieving this outcome should be fully reproducible and applicable both in a fresh dev environment and in our production K8s environment, the latter being critical to ensuring we are able to deploy VegBank to production as part of our final rollout.
Details
The objective here is twofold:
Assume that the DB contents will be provided as a full dump file from the original production database, and for any & all future fresh deployments, a then-current version of this dump file will likewise be provided.
Acceptance criteria
Related issues
The text was updated successfully, but these errors were encountered: