Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VegBank DB deployed to K8s dev cluster #39

Open
6 tasks
regetz opened this issue Nov 25, 2024 · 0 comments
Open
6 tasks

VegBank DB deployed to K8s dev cluster #39

regetz opened this issue Nov 25, 2024 · 0 comments
Assignees
Labels
📘 Epic Targeted capability, feature, or finding D-2.1 Refactored data model and design plans

Comments

@regetz
Copy link

regetz commented Nov 25, 2024

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:

  1. 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.
  2. 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

Related issues

@regetz regetz added 📘 Epic Targeted capability, feature, or finding D-2.1 Refactored data model and design plans labels Nov 25, 2024
@regetz regetz moved this to In Progress in VegBank Project Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📘 Epic Targeted capability, feature, or finding D-2.1 Refactored data model and design plans
Projects
Status: In Progress
Development

No branches or pull requests

2 participants