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

Document expectations around development and local database instances #199

Open
2 tasks
TangoYankee opened this issue Apr 1, 2024 · 3 comments
Open
2 tasks

Comments

@TangoYankee
Copy link
Member

TangoYankee commented Apr 1, 2024

Background

PR #198 introduces a remote 'development' database that is available to local development. We should have a team discussion to ensure we have consistent and maintainable expectations around the use of this environment.

Acceptance criteria

  • Reach a consensus on DB usage
  • Document in the readme
@TangoYankee
Copy link
Member Author

My philosophy is to have a one to one relationship between application and database instances. In other words, a development database should exclusively serve one development application. Accordingly, local applications would be served by only local database instances.

However, I recognize that some folks will want to avoid setting up the database locally just to make changes to the API. As a compromise, I suggest we still provide the development database. However, it is only used for tickets that do not require database schema changes. Any work that requires modifications to the database schema must be done against a local database instance.

@damonmcc
Copy link
Member

damonmcc commented Apr 1, 2024

The changes in #198 are so that a deployed remote API can use a remote database (dev, staging, or prod)

If making it impossible for a local API to use a remote DB is a requirement, any ideas on how that can be prevented?

@TangoYankee
Copy link
Member Author

If making it impossible for a local API to use a remote DB is a requirement

Documenting an offline discussion around this:
Making it technically impossible for a local api to use a remote db is a non-goal. This is more about establishing cultural workflow expectations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants