Should we seed staging on every deploy?

[deivid-rodriguez]

Currently the seed process is very slow and makes consecutive deploys fail.

I was thinking that we could pg_dump a brand new seeded DB, and then pg_restore on deployment, but then I realized that seeds in decidim don't lead to a known fixed state, but instead seed random data so I'm not sure reseeding actually buys us much, since the final state will be "random" anyways. Should we instead leave staging data untouched?

[leio10]

I'll be working on seeds these days. The idea of reseeding on every deploy is to have a fresh installation with every change, but I'm open to change it. Also, after we deploy to production we will need a place to check if changes work well over existing data.

[deivid-rodriguez]

Actually I feel not deleting and reseeding test data better checks "if changes work over existing data". Because it will exercise migrations over the existing data (if the deploy includes migrations) and potentially surface data migration problems.

The thing is I'm not sure if a freshly seeded DB on every deploy buys us anything. Not seeding buys us a lot of time on every deploy...

[leio10]

Fixed on #55