# Writing a one-time script in Rails

DevFeed: [Writing a one-time script in Rails](<https://devfeed.tech/articles/writing-a-one-time-script-in-rails-26280.md>)

Original publisher: [Read original article](<https://www.justinweiss.com/articles/writing-a-one-time-script-in-rails/>)

Author: Justin Weiss

Published: 2017-02-14T06:08:51Z

Content type: tutorial

Language: en

Sources: [Justin Weiss](<https://devfeed.tech/sources/justin-weiss.md>)

Topics: [Rails](<https://devfeed.tech/topics/rails.md>), [Script](<https://devfeed.tech/topics/script.md>), [data](<https://devfeed.tech/topics/data.md>), [migration](<https://devfeed.tech/topics/migration.md>), [import](<https://devfeed.tech/topics/import.md>), [CSV](<https://devfeed.tech/topics/csv.md>), [Database](<https://devfeed.tech/topics/database.md>)

Tags: [capistrano](<https://devfeed.tech/tags/capistrano.md>), [csv](<https://devfeed.tech/tags/csv.md>), [data](<https://devfeed.tech/tags/data.md>), [database](<https://devfeed.tech/tags/database.md>), [heroku](<https://devfeed.tech/tags/heroku.md>), [import](<https://devfeed.tech/tags/import.md>), [job](<https://devfeed.tech/tags/job.md>), [migration](<https://devfeed.tech/tags/migration.md>), [other](<https://devfeed.tech/tags/other.md>), [rails](<https://devfeed.tech/tags/rails.md>), [rake](<https://devfeed.tech/tags/rake.md>), [scheduler](<https://devfeed.tech/tags/scheduler.md>), [script](<https://devfeed.tech/tags/script.md>), [sidekiq](<https://devfeed.tech/tags/sidekiq.md>), [structure](<https://devfeed.tech/tags/structure.md>)

## AI overview

This Rails tutorial explains how to handle one-time data tasks, comparing database migrations with rake tasks and scheduled background jobs. It recommends rake tasks for code that must be tested locally and run in production, while noting when migrations are appropriate and what risks model changes can create.

## Source excerpt

Have you ever wanted to import a bunch of data into your app from a CSV file? Or maybe you need to fix badly encoded characters in some of your customer reviews. Or you changed your mind about how you wanted to store data in Redis, and had to move everything from the old format to the new one. At Avvo, we called these "ad-hoc tasks." As in, you probably only need to run them once. So what's the best way to handle an ad-hoc task in Rails? Write a database migration A migration works well if you need to change the structure of the data in your database. It tracks whether the task was run, it carries over changes to other environments - it's what migrations were built for. It's also what you're probably already using them for. If you're changing data at the same time, a migration might work well. But there are some things to watch out for. Calling something like Permissions.create(...) in your migration can cause you trouble. If the model has changed, your migration might break, because your model might not be available when the migration runs. Or your model might have changed between the time you wrote the migration and when it ran. There are ways to get around this, but they're error-prone and can fail in weird ways. Migrations are also less useful if your task doesn't involve ActiveRecord. These aren't deal-breakers. But I tend not to import or change much data in migrations. There are better options. Write a rake task You have a task. You probably only want to run it once. And you want to be able to test it on your machine and run it in production. Rake tasks work really well for this. Rails can even generate rake tasks for you: $ be rails g task locations import create lib/tasks/locations.rake This creates a file for you to stash your code into: lib/tasks/locations.rakenamespace :locations do desc "TODO" task import: :environment do end end Inside that task block, you can use all your models and the rest of the code in your Rails app. It's easy to import and chang