Should we have a conventional namespace for data migration rake tasks?

[eoinkelly]

Most apps I have worked on need a "one time only" rake tasks which perform some kind of data migration of production data. I have a strong preference for migrating data in a rake task and only changing database structure in migrations (whenever possible, sometimes you have to use migrations).

Each time I have had bikeshedding conversations with the teams on those projects about what namespace we should put that task in: none, temp:, one_off:, data_migration: etc. These conversations seem like quite low value so I think it would be good if this template expressed a preference by creating a file under lib/tasks with a comment encouraging devs to put this kind of task in the file.

For example:

# lib/tasks/data_migration.rake

# Use this namespace for data migration tasks e.g. a one-time data migration of
# production data. 
#
# You may want to periodically delete old tasks from this namespace if they
# don't provide ongoing value to the developers.
# 
namespace :data_migration do
  # desc "Update user data because ...."
  # task 2022_03_update_users: :environment do
  # end
end

[robotdana]

i'd love to compare our preferences for one-time-only data migrations, to me they go in db/migrate and should be written with sql directly and not rely on models or activerecord

[robotdana]

but this example with the timestamp in the name and the desc and data_migration as the namespace feels good if we must use rake tasks

[robotdana]

if this data migration can be rolled back that's another reason to put in db/migrate

we'll probably make this a confluence/notion page rather than part of rails-template as there are pros and cons to the various approaches and they suit different circumstances

[eoinkelly]

Another approach from my current project is a ./one-off-scripts directory in project root which contains Ruby files run via bundle exec rails runner ./one-off-scripts/do_thing.rb

I like that this makes the nature of the scripts a bit more obvious and makes it clearer that future dev can delete this script once it has run