How do you personally do release cycles on your QuickBase realm?

Question

I know QuickBase gives us the ability to make changes on the fly and not have to deal with the normal software release cycle. I'm just wondering how others treat this. I'm curious about the benefits or disadvantages you have seen with different release cycles.

Do you do a weekly/monthly release where all of the changes are added at once via a sandbox?

Do you make copies of the app and figure out what needs to be done for a change and then replicate it in production on the same day?

Do you just work straight in production without worrying about a sandbox or app copy?

Maybe even something else? I'm sure there are other options and if you do it differently I'm interested in hearing why.

BreeMackey · Answer

Hey Austin --Great question, one that I spend a lot of time discussing with our clients. Before joining the QB team, I was the Release Manager for a large financial services company, designing release ceremonies in compliance with security needs and best practices.We were Agile teams working 2-week sprints, so do keep in mind your mileage may vary.Due to security compliance, developers were not allowed access to Production unless it was an emergency.We set up a dedicated copy of our Application (Staging).That application included reproduction of any integrations present. So if there was a connection to Salesforce, we would connect this Staging application to the requisite Salesforce Sandbox.A detailed 'story' or ticket was required for every change. (Those went through a rigorous approval process, but that's a different animal). The builder would make the changes in Staging, documenting those changes in the story record.Changes were tested by either Quality Assurance or User Acceptance testing based on the criticality of the change.We had a set release day every 2-weeks.That way my end users were prepared that every other Thursday they could potentially see changes. This helped set expectations, and minimize confusion.On Wednesday night (after hours) or Thursday morning (before hours) I would make the changes in the Production Application as directed by the original builder.I would email out an update once the changes were live, including the release notes outlining the changes.This helped keep help tickets to a minimum, because users knew which changes/functionality were supposed to be there vs something actually wrong.Bug fixes were taken on a case-by-case basis depending on criticality.Obviously, I worked in a highly-regulated industry which dictated much of our processes. For most clients I highly recommend using some sort of ticketing application to track changes to your QB app(s). That makes your life infinitely more easy when something goes wrong and maybe you didn't build it, but the person who did is on vacation. Having a dedicated cadence for deployment sets you up for scaling your operation in the future. It also gives you (and other builders) some breathing room while setting change expectations with your users. I think we've all worked at some point in a 'drive-by' environment. Where someone stops by your desk and orally asking for a change...that's not sustainable! You want to plan for success!If you're interested in hearing more about this (ALM and Governance are two of my passions!), reach out to your CSM and let them know you'd like more guidance in this area!------------------------------Bree Mackey | Solutions Architect------------------------------

Sign up

Login to the community