Database access for contributors

1

I have a project at https://github.com/ozzym1096/ecomm-demo and would like for other people to be able to work on the back end code (i.e. work with the DB). Is there a standard way to let contributors be able to test with the DB locally? Or would I just tell anybody that wants to contribute to create a DB on their local machine? Obviously I can’t share the DB URI with just anybody, so I’m not sure how people usually handle this.

Thanks for any help!

2

Probably the simplest is to just document how to connect to a database instance locally.
There are other alternatives, like using something like Docker+docker-compose to handle it, but then you have the issue of dealing with Docker and documenting that approach as well. (last I checked thats how fcc handles it)

Another possibility is having contributors provide credentials to some system that gives them access to a given database instance, but this is vastly more complicated and not worth it.

1 Like
3

Thanks for the response! Just so I know I understand, if I want to keep it simple I would just document the DB schema so anybody can create their own DB locally?

4

You’d want to lower the barrier to entry as much as possible, so documenting some “bootstrapping” code that creates all the schemas for them could be provided. So the instructions could be similar to:

  1. install database software here (link to the database technology, and docs)
  2. provide the connection information as (how to setup environment variables, or whatever to connect)
  3. run “bootstrapping” code to build the schema (write some other code that can be ran before doing anything to create the database structure required by the app)
  4. develop :smiley:

Otherwise developers will have to kinda “guess” what the database looks like, and potentially deal with changes to it overtime. Where-as a setup that is “automated” by the code itself means you can handle that yourself. Yea its more work, but its vastly easier to contribute too.

Another consideration is to add a “tear-down” script that can be ran to remove the “bootstraped” database used for contributing to. This way if there is database migration/schema changes, developers can just teardown and rebuild it from scratch. Yes they lose their data… but this is local development, it shouldn’t matter :slight_smile:

And again, documentation is key. So documenting how to use all this stuff to get going is all part of getting contributors to help, or at least familiarize people who do want to help with the project.

5

Thanks for all the help! This is the first project I would like to have collaborators on, and I couldn’t find any good answers for this specific problem. If anything, now I know that documentation is everything :sweat_smile: