What types of developer environments are you using in place of sandbox ?

  • 0
  • 1
  • Question
  • Updated 3 years ago
  • Answered
Photo of Richard

Richard

  • 40 Points

Posted 3 years ago

  • 0
  • 1
Photo of QuickBaseCoach App Dev./Training

QuickBaseCoach App Dev./Training, Champion

  • 62,448 Points 50k badge 2x thumb
1. Make back up copies of the app before making dangerous changes which could lose data. That way the lost data could be imported back into a field, for example.

2. Actually do the work twice, once on a copy of the app, and then carefully make the changes on the live app.

3. Just be careful.
Photo of Richard

Richard

  • 40 Points
Thanks that seems to be the consensus of other posts.
We have a dynamic environment here  and sometimes there is more that one developer in an app at the same time.

My partial solution was to build a change management app that would track change requests and include a  data dictionary and a place for the developers to check in their changes.
And we have lots of backups both inside Quickbase for data and structure  and we also use the QB MS access desktop app. for data. The Access desktop is also helpful in generating the Data dictionary.

I would like to minimize the duplication of effort and have less dependence on step 3.
Perhaps the new Quickbase will investigate if a lower price point for for the Sandbox will generate enough sales to increase revenue.
.
Any other tips out there ?
Thanks
Photo of Harrison Hersch (MCF)

Harrison Hersch (MCF), Champion

  • 40 Points
The sandbox works really well but has a limitations. I've found it works for about 80% of changes needed but if you are performing deletions or some other changes, you will need to duplicate them.

The posts above are solid with regard to strategies. You may find that building a change management app works, but begins to erode some of the value of QuickBase and how quick it is to manage change. It is kind of a catch 22 in the sense that QuickBase is so fast because that is great, but also introduces risk. Perhaps build a risk scorecard of things your teams can do inside of production and that need to be first validated in a development environment. Even if you do validate the changes in dev, you still have the risk of human error when reproducing in production.

The other caveat is scripts/integrations. If you decide to have some .NET that handles the data integration with another system, you probably will have a dev version of that. So in reality, you wind up having duplicated scripts as well as duplicated apps.