Script Management, Version Control, and GitHub

Yes. It is far too easy to accidentally overwrite a custom script, both in scripting extension and automation scripts.

I keep scripts in a git repository. I use a regular repository, not gists.

If you do not store your scripts outside of Airtable, you can try restoring a snapshot of the base and get the version of the script as it existed at the time the snapshot was taken. If your script contains anything that looks like an Airtabld ID, be prepared for it to be “updated” to a new value in the script. I view this as a technique of last resort. It is far better to always store scripts outside of Airtable. 

Hey @mcordier! 

This'll be a bit of a brain dump.

Over the past two years, the subject of Airtable's scripting automation runtime has started to become a regular occurrence in my discussions on the platform.

My current method isn't too far off from what you've described. Instead of leveraging GitHub Gists to store scripts, we lean towards storing Airtable scripts into individual repositories for our larger Airtable products.
Scripts aren't the only things you'll find in those repos. In addition to scripts, we store larger formulas and accompanying documentation about respective scripts, formulas, and the base schema overall.

Our more generic scripts are stored in a general purpose repository that functions as a pseudo-library.

It's not sustainable or scalable, but it's organized and it's serving its intended purpose, which is to provide a temporary solution until either (a.) Airtable implements a more robust metadata, schema, and automation version control solution that allows developers to interact with Airtable in a git-controlled environment or (b.) we are forced to externalize our automations into a microservice infrastructure.

I've already externalized many of my Airtable automations into microservices, but not at scale.
Airtable is vocal about the flashy, marketable updates it makes to the platform, but they don't publicize the updates being made to the Web API. Those changes and expansion of the API have made it easier to externalize services, albeit the process has been slow.

The need to do this is really punctuated by the lack of a secret management solution in Airtable's automation environment. There are a scary number of valid and hot credentials sitting forgotten in people's bases and automations.

Externalizing my automation infrastructure has also opened the door to being able to write my services in TypeScript, which has been immensely valuable to the overall readability and maintainability of what would otherwise be a massive and incredibly daunting scrollfest of JavaScript.
Naturally, doing this brings about a lot of challenges, the biggest one being how to authenticate requests invoked from Airtable, but there are a few crafty ways to do this.

Here because I had two tabs open, closed the one I'd been working on for an hour and then accidentally went into the old tab which overwrote my script in airtable. Unfortunately, the snapshot isn't granular enough to restore the script I worked on. Airtable should have versioning enabled with the autosave functionality.