My opinion has changed over the years; I don't see value in maintaining
migrations when prod must be the single source of truth on the schema. Better
to pull the schema from prod than maintain a brittle set of scripts to
reproduce it.
As is traditional for every Rails point release, the asset pipeline broke in a
new and obtuse way. In this case, by hanging puma indefinitely after serving
any page, requiring a kill -9. Pinning an old version; I'll burn 20 hours
unfucking whatever new wrong thing it's doing later.
The asset pipeline is nine years old.
After this `bundle outdated` shows only 2 packages:
1. capybara which depends on ruby >= 2.4, should be bumped for the rails 6 update
2. tzinfo which is locked to 1.x by activesupport
We haven't attempted to maintain support for it as we've increased our custom
SQL, and it's long been best practice in Rails to use the same database system
in dev as prod.
While the previous approach of hand-rolling test data cleanup + setup works
it’s prone to become insufficient with regards to future test scenarios. Recent
commits 6a6da094 and later 4620a9221 highlight the issue.
Using the database cleaner gem provides a cleaner (pun intended) approach to
setup a clean room environment before and after each specific test.
Annotating specs with with `:js` or `truncate` will switch from a transaction
based cleanup strategy to a truncation based one to enable feature/request specs
for which a web server is spun up in separate process by RSpec, in other words
the process executing the spec is not the same as the process handling the
request so RSpec/DatabaseCleaner wouldn’t know when to rollback the transaction.
The downside of this approach might be that RSpec takes a few more seconds to
run all specs.
