How to deal with migrating development changes to production base?

[0800-grizzly]

Hi,

I'm approaching launch for my first Airtable application, a support/ERP/CRM system for my wife's business (two users currently planned). Is there an agreed upon best practise how to launch a production version but yet be able to continue developing the application?

I have little real experience in application management, although I have managed some LAMP applications with SQL updates and diffing PHP. 

I thought I would keep the current base as PROD, make a back-up of it and assign that a DEV role and continue developing new stuff there. But how to migrate changes from DEV to PROD?

Rgds,

Björn

[ScottWorld]

Airtable does not have the ability to migrate changes from one base to another base, because Airtable is not a programming language like what you are used to.

Airtable is more of a spreadsheet with some database features added to it, so think more along the lines of Microsoft Excel.

You could make changes in a DEV copy of your base to test things out, but then you would need to manually rebuild all of those same changes from scratch in your PROD copy of your base.

Everything would need to be completely rebuilt from the ground up — all of your formulas, automations, views, interfaces, forms, everything.

A slightly easier way of doing the migration that would require slightly less rebuilding would be to outsource as much as possible from your Airtable base to external 3rd-party tools, and just use Airtable as the backend to hold your data.

For example, if you’re looking for an easier way to migrate your forms, you would want to use Fillout’s advanced forms for Airtable, which offers over 100 advanced form features that Airtable’s forms don’t offer.

You could test the forms with your DEV base, and then when you’re ready to switch to your PROD base, you would go through all of your fields and remap them to the new base.

It’s an even easier process with automations.

If you want an easy way to migrate your automations, you would want to outsource all of your automations to Make’s advanced automations for Airtable, and then you would just need to change all of your modules to use the PROD base instead of the DEV base.

Same thing with interfaces.

You could build your interfaces with any of the advanced interface tools on the market such as Noloco’s advanced interfsces and portals for Airtable, and then just remap everything in your interfaces when you’re ready to make the switch from DEV to PROD.

Or, even better, just build your interfaces to work with PROD, but don’t publish the changes until you’ve fully tested it with PROD.

p.s. If your company has a budget for your project and you’d like to hire an expert Airtable consultant to help you with any of this, please feel free to contact me through my website: Airtable consultant — ScottWorld 

[kuovonne · Accepted solution]

Airtable currently does not have a method for migrating changes from a DEV environment to a PROD environment. 

- Do not try to keep a DEV base in parallel with PROD. People tend to build things in PROD like filtered views, even if they are not creators. It is also really tempting to make really small changes directly in PROD. Both of these things make it really easy for your DEV base and PROD base to get out of sync. Instead, when you want to make significant changes, duplicate your PROD base to a DEV workspace and test out our changes there before manually migrating change to PROD.

- When writing scripts, use field and table names instead of IDs. Different bases will have different IDs. Avoid hardcoding any type of Airtable ID in a script, if possible.

- When writing formulas that build URLs using share links, keep careful track of where the formula points to for each base. It is too easy to end up with a formula field in the duplicate base that points to a URL for the original base.

- When building 3rd party integrations, limit how aware the 3rd party is of the actual Airtable base. For example, I call my Make scenarios via webhook with any necessary data, and have the scenario return data the same way. That way I can use the same Make scenario with both my DEV and PROD bases without any changes in Make.

[0800-grizzly]

Thanks Scott,

Then I know there's no functionality for this. I however disagree a bit with your statement that such functionality can't exist in Airtable. Database structures and such should be possible to move over, there is some kind of SQL in the back end. Could be tricky yes, but not impossible as I understand it.

I'm expressly trying to avoid extra services, would actually like to get rid of Calendly also :).

Rgds,

Björn

[0800-grizzly]

Thanks Kuovonne,

This sounds like good and solid advice given that Airtable doesn't have any such functionality. Makes it somewhat more stressful for me, since I'm a bit all over the place with changes. Need to be more disciplined then :).

Rgds,

Björn

[ScottWorld]

---

@0800-grizzly wrote:

Thanks Scott,

Then I know there's no functionality for this. I however disagree a bit with your statement that such functionality can't exist in Airtable.

---

I never said it CAN’T exist. Airtable can choose to build any functionality into their product that they would like to build into it. I said it DOESN’T exist. Come back to Airtable in 5 years, and it might be a part of the product then.

[0800-grizzly]

Scott,

I apparently misunderstood how you meant this, my apologies:

"Airtable does not have the ability to migrate changes from one base to another base, because Airtable is not a programming language like what you are used to."

Regards,

Björn