In a previous tip, I explained that we pushed back on a request to build a bulk import feature for a client because it was a one-time need. So what did we do instead?
One thought might be to just import the data directly using a database management tool, but this wouldn't work. Not only would it bypass validation logic and role creation, we'd have no easy way to send the welcome email notification to the new users.
Another temptation might be to just write some ad-hoc code in a Tinker session. While technically possible, this still feels too risky to me. If we got something wrong, we could send out incorrect welcome emails or have to clean up bad data. Plus, we don't even install Tinker in production.
Our approach was to build a command, even knowing that it would only be used one time. Why? There are a few reasons:
First, going through our normal release process means it will go through code review. This could potentially catch issues.
Second, we now have a permanent record in git of what this command did. Even after we delete the command, we can reference it in the git log. You can also tag a commit if you want to make it easier to find in the future. You don't get that with Tinker sessions or database management tools.
Finally, let's say a second or third company also requests a bulk import feature, we now already have a good chunk of the feature code written to do it. We can later refactor this command code into something a user could access through the interface.
Here to help,
Joel
P.S. Validation is really important in your app, but it doesn't always get the attention it deserves. We've written the ultimate guide to Laravel validation rules to help you get the most out of this powerful feature.