| It looks like using Rails test fixtures (reborn) to create seed data. Which is an OK win I guess, and having it separated out by environment (implicitly mentioned in the article) is nice.. but I don't see how much of a win this is over instantiating fixtures or FactoryGirl.create in your seeds.rb file. Yes, there are tons of problems with using db/seeds.rb for anything serious. I'm not sure that Sprig will handle my issues much better than I currently do myself. For the record, my desired behaviors for a seed data solution are: 1. environmental separation (which Sprig has). Developers have different needs for seed data as QA does, as does the staging server, as does production. Developers want an easy default dev@myco.com user with a simple password, but you don't want that in production. 2. If I rerun my seed solution (perhaps because I added some more seed data) it shouldn't duplicate records (or throw errors because it's trying to create the second user with the same email address) 3. Handle bootstrap data I need in my app (example: I want a list of US states, and every environment should get this. To reiterate my second point, I should be able to add to this bootstrap data without getting two copies of "California" in my US state list). It's sad that no real solution exists to handle all three of these needs. Some projects I've been on have gotten this close, but that was years ago and things have changed. (If Sprig does have these things, then that's the selling point, not seed data as fixtures which the article emphasized) I'm also not sure about using fixture like things in Sprig. I give it 6 months before most users remember why many people in the Rails community moved to a Factory pattern for (test) data construction long ago. However, I am happy that a relatively well known Rails consultancy is released 1.0 of a seed gem. Hopefully the name recognition / noise will lead developers to the gem and I'll be a better solution with many more eyes. |
https://github.com/james2m/seedbank