Discussions

 View Only
  • 1.  How do you personally do release cycles on your QuickBase realm?

    Posted 11-22-2019 18:46
    Edited by Austin K 11-22-2019 20:50
    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.


  • 2.  RE: How do you personally do release cycles on your QuickBase realm?

    Posted 11-25-2019 10:32
    I have a love/hate relationship with this but cannot splurge for sandbox mode right now :)

    I try to do bug fixes immediately and I do not communicate most of those.  I do most of my feature stuff at night or preferably over a weekend tied with a Monday summary send to the entire company of what changed.

    if I do a new feature release during the day I just make sure I am 100% confident it is an easy thing and I don't need to test it.  I pre-write the notification of what is coming and send that out and say it will be available within the hour.

    ------------------------------
    Ivan Weiss
    ------------------------------



  • 3.  RE: How do you personally do release cycles on your QuickBase realm?

    Posted 11-25-2019 10:46
    This is something that we are working through right now. Previously we have used a mix of building in production for small changes and making a copy of the app to firm up a medium to large change then implementing it into production. We are testing out the new Sandbox feature and will likely move to a more regimented release schedule (my guess would be monthly for minor changes and quarterly for major changes) in our large applications.

    ------------------------------
    Jacob Linn
    ------------------------------



  • 4.  RE: How do you personally do release cycles on your QuickBase realm?

    Posted 11-25-2019 12:52
    Edited by Bree Mackey 11-25-2019 12:52
    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.

    1. Due to security compliance, developers were not allowed access to Production unless it was an emergency.
      1. We set up a dedicated copy of our Application (Staging).
      2. 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.
      3. 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.
    2. Changes were tested by either Quality Assurance or User Acceptance testing based on the criticality of the change.
    3. We had a set release day every 2-weeks.
      1. That way my end users were prepared that every other Thursday they could potentially see changes. 
      2. This helped set expectations, and minimize confusion.
    4. 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.
    5. I would email out an update once the changes were live, including the release notes outlining the changes.
      1. This helped keep help tickets to a minimum, because users knew which changes/functionality were supposed to be there vs something actually wrong.
    6. 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
    ------------------------------