3 Replies Latest reply on Apr 20, 2011 11:05 PM by aconnercoash

    Best practices for managing Production code drops and UAT environments

      Hello External Comm friends,

       

      We're wrapping up our development efforts as we prepare for our long awaited public launch. To this point we've maintained the "Felix Unger" of UAT environments (read = uber clean and tidy...and depending on the PS guru you ask..just as anal). Keeping this part of the house in order was no easy task given a couple of our more involved customizations. During our development period there were (and continue to be) times when it felt like a game of Whack-a-Mole - every bug we'd find and fix seemed to uncover or birth another one somewhere else.

       

      Anyhow, we've just wrapped up our UAT --> Production refresh so our Production environment could match our polished UAT environment. But given my experience so far chasing ghosts with all these little issues that keep cropping up, I'd be naive to believe that suddenly our Production environment will remain as squeeky clean as the day she was born.

       

      To that end, I'd love to hear from the group about how you're managing your UAT and Production environments. Are you fixing bugs in Production only, then periodically doing a Prod --> UAT refresh? Are you fixing issues simultaneously? Anything to do with your running and management of both environments would be helpful to me.

       

      Thanks in advance for your response. I look forward to hearing from you.

        • Re: Best practices for managing Production code drops and UAT environments
          wengla02

          We currently have three environments:

           

           

          1)      Dev (on the developers workstation, pointing to Test DB)

           

          2)      Test

           

          3)      Prod

           

          When we encounter an issue, or we make a significant change we’ll work it out in Dev/Test first, then push the change to Prod.  We are working very very hard to keep both environments free of custom code.  We find that any change we make adds dozens of hours to future patch releases.  Since Jive is still working on the open source ‘Release early, release often’ model, we need to keep the LOE for patch updates low.

           

          For each major update, we refresh the DB from Prod back down to Test so the content matches before we begin development.

           

          So, to sum up – code / FTL fixes go Dev – Test – Prod.  DB changes go Test – Prod.  And once in a while we flash Prod – Test before a significant project.

           

          Will

            • Re: Best practices for managing Production code drops and UAT environments

              this is really helpful Will. For better or worse, we've got a considerable number of customizations that require quite a bit of testing in both environmnets (UAT and Prod) for every bug fix and code drop. But i'm happy to hear you validate that Prod --> UAT DB refresh before any significant code work takes place.

               

              Thanks again for sharing.

                • Re: Best practices for managing Production code drops and UAT environments

                  We are currently hosted and have a highly customized code base. Once the code is developed in a DEV environment it is implemented to UAT for QA testing. We go through "fixes" from UAT feedback, but all the dev is done in a different environment and then implemented to UAT for validation. Once all is tested we implement the approved code to PROD.

                   

                  In regard to discovering issues and bugs, depending on the environment we find them in, we check them against the other environment and against other instances of Jive that we have (We are currently running 3 different sites on Jive) and report the issue accordingly. That way if we find an issue in PROD we can see if the code to come that is in UAT will resolve the issue or not. If it is an issue we find in UAT, we test PROD to make sure there isn't a bug we haven't found or if there is a new bug being introduced in the latest code.

                   

                  Bottom line for us is that we do not intentionally put anything in to PROD without vetting it in UAT first.