Skip to main content
Question

Keeping a Production and QA/Staging App in Sync?


Hi everyone, 

So in my world we have a concept of Production and Staging.

In production, changes are done using the Sandbox, while new pipelines are built in staging (since pipelines can't be used in the sandbox). 

Main issue I've run into , that cause me some headaches: 

  1. I can't take my schema changes from the production app sandbox and duplicate them in staging. I have to manually make the same schema changes in 2 apps to maintain consistency during development to ensure people can test the changes End to end.
  2. Developing pipelines in the "staging" app, and moving to a production pipeline (that works against the production app!) requires a deep audit of the pipeline, since the staging and production apps aren't identical in field ids (sometimes) , and the account slugs / table ids between Production and Staging are different. Generally easy to change via the YAMLs, so far less of a headache then #1

I've experimented with a couple things, but feel I am missing a key component Quickbase has that helps keep 2 apps in sync? 

  • I don't want to marry prod data with Staging - so connected tables I feel won't work...? 
  • Copy table from prod to staging, won't work since staging has table in identical names (so I can delete and copy from production? that doesn't sound desirable)
  • Neither those table movement solutions keep table to table-relationships 

What seems like the easiest solution albeit not easy is:

  • Copy the production app (without data) after every release, and make a new staging, I still have the issue of having to update all the pipeline slugs, and tables referenced in my old "staging" pipelines....while losing all the staging test data. This gets cumbersome with over a dozen pipelines. But seems like the best solution for now.....

Thanks for pointing me to any viable alternative solution, or at the very least sharing some ways to accomplish this. 



------------------------------
Jamie Gray
------------------------------
This topic has been closed for replies.

Forum|alt.badge.img+9

Open forum to everyone else's best practices, but in general I have the same approach and general annoyance with what you're describing. For the bulk of our production apps I follow the same approach you have in that staging is a copy of the production app and all development done in Prod or approved from Staging must be duplicated/reworked in the other application. I almost never use the out of the box sandbox that QB provides given the lock that it places on Prod and the short term / all or nothing nature of the environment. 

Our implementation process is to develop everything in staging first so the two environments stay in sync and have minimal deviation and then port to production once approved and validated. 

To my knowledge there is no way to truly do a prod/staging/sandbox setup in the classical IT way of thinking about it. 

Typically our sandbox/development environments live for 3-6 months so while its a headache, I've found that being diligent about keeping the two environments in sync allows that timeline to extend, but this is a core feature that needs some focus for larger/more controlled enterprises. 



------------------------------
Chayce Duncan
------------------------------

  • Registered
  • July 18, 2023

My hope is that the newly released Solutions module for versioning of an environment (apps, pipelines) will eventually allow you to deploy a new instance of a Solution. Right now Solutions are basically snapshots of an environment that allow you to rollback, but it shouldn't be a far reach to use the Solution for deployment.



------------------------------
gary
------------------------------