For a recent project, I've found myself writing quite a few one off scripts for database adjustments, SQL queries for analytics, etc. I've been manually running them myself in the command line, but it's a very messy process. New team members also don't know what scripts are available and where to look. Anyone know of any tools, or have any workflows to better organize these scripts?
If they were truly one-off, you wouldn't need to manage them. Categorize and document. SQL queries for analytics go into something like Metabase. Database migrations go into git. Frequent adhoc scripts go into something like Jenkins so you can trigger them easily. So on and so forth. All of those documented somewhere, like the team's Confluence/Notion/whatever.<p>But don't just leave them at that, do work on eliminating their need. Sisyphean task but necessary nonetheless.
Add them to the repository and treat them like you would treat other code. Chances are, they'll become some sort of tooling later when people tweak them, improve them, make them modular, generalize them.<p>We introduce many things that way. First it's just a few commands that do something useful. Then included in the repo. Then tweak. Next thing you know there's an endpoint with that functionality because it's useful and frequently needed.
The classic is the /scripts directory in your codebase (presumably in VCS). The key is also to trawl through occasionally and remove anything that hasn't been used in a while.
If it’s truly one-off (like codemods), I put the scripts in relevant tasks and diffs for reference.<p>…otherwise we just throw everything into a scripts directory. Keep it flat until it feels messy, then start organizing. All documentation must live with the code, otherwise it gets out of date too easily.
Funnily, wasn't there just a launch HN yesterday that helps with this: <a href="https://news.ycombinator.com/item?id=28156461" rel="nofollow">https://news.ycombinator.com/item?id=28156461</a><p>Oherwise, I just use git like others said but that can be suboptimal for non technical or semi technical users.
If it's one-off but has to be worked on for some time, with testing and whatnot it may be placed in a folder for maintenance scripts in the repo. Once it's been executed it can be deleted from source control
At a prior company we added them to a folder of misc scripts along with notes on what they were for.<p>Not the greatest solution but it did ensure they never got lost.