This is one of the action items that resulted from the last developer mumble meeting.
Tha main goal of this task is to provide some meaningful seed data. From the official Rails guide:
To add initial data after a database is created, Rails has a built-in ‘seeds’ feature that makes the process quick and easy. This is especially useful when reloading the database frequently in development and test environments. It’s easy to get started with this feature: just fill up db/seeds.rb with some Ruby code, and run rails db:seed:
This is generally a much cleaner way to set up the database of a blank application.
In OFN repository we use seed data only to populate
Spree::State tables for Australia. Look at db/seed.rb for more details.
Furthermore we have a different behavior between running the app in
development environment in a local machine and provisioning a
staging environment with our Ansible playbooks. More info here.
In any case we just seed contry and state data, nothing else.
The problem is that running a new instance of OFN (no matter if
production) will lead you to an empty shell that cannot be used right away. For instance you cannot try the app since to see a valid shop you need to create an enterprise and at least one product. But when you’re going to create a product you discover that you must create some category (taxonomy) first… and so on.
This makes difficult and tedious to manually test basic behavior while developing and difficult to understand trying to run a production instance for the first time.
When I asked people in
#dev channel how do they deal with this problem the response I got was that we move around DB dumps. Basically snapshots of the state of the DB at some (unknown) point. This is not ideal.
What we agreed in the meeting is to start this discussion and try to detect the basic data needed to make a health check of the app. I’ll start proposing a basic setup so we can discuss:
Right now we only have the super admin user that Spree seed data provides:
firstname.lastname@example.org. In addition to that would be nice to have:
- a normal enterprise admin
- a customer
Nice to have:
- an enterprise (1 for each type if possible, we can iterate over it)
Some category for the products. The problem here is that every OFN instance uses a different taxonomy. Maybe we can create a default one just to test the app and override in production or find a way to seed data based on some conditional.
For the spanish OFN instance we started working on a repo to use for
staging. Maybe we can find a way to use it seeding the DB in
development too, still not sure about it.
Some product for each enterprise.
Since I’m new to OFN please feel free to correct me if I’m wrong.
I was thinking about working on a first PR to make some real proposal. What do you think? Am I missing something important? Thought? Rants?