Post reply

Approaches for creating a test environment

  • December 11, 2014 at 7:50 am

    #301754

    Hi all,

    I am try to put together options in regard to creating a test environment for our Dynamics NAV system. The environment will be mainly used to test new releases / changes ahead of applying them to production.

    The 2 options I am considering are…

    1. Create a second Test instance on our Production SQL Server to host a test database

    2. Purchase a set of SQL developer licences and having a totally separate server for our test environment.

    My preference would be option 2. However I need to build a convincing case that this is the best way forward. I wondered if I could tap into the thoughts of the SQL Central community and see how other approach this. Any guideance you could share would be much appreciated.

    Many thanks

  • December 11, 2014 at 8:01 am

    #1764075

    TerrenceTheCat (12/11/2014)

    Hi all,

    I am try to put together options in regard to creating a test environment for our Dynamics NAV system. The environment will be mainly used to test new releases / changes ahead of applying them to production.

    The 2 options I am considering are…

    1. Create a second Test instance on our Production SQL Server to host a test database

    2. Purchase a set of SQL developer licences and having a totally separate server for our test environment.

    My preference would be option 2. However I need to build a convincing case that this is the best way forward. I wondered if I could tap into the thoughts of the SQL Central community and see how other approach this. Any guideance you could share would be much appreciated.

    Many thanks

    I absolutely agree with Option 2 rather than Option 1. Option 1 just opens the possibility of someone not paying attention and doing something incredibly wrong to production data. It also opens the possibility of a massive slowdown for the production system if someone makes a mistake on the test system. You also have to consider any automatic backup routines that might pick up on the new database(s), etc, ad infinitum. You'd also have to allow people that probably shouldn't have it access to the production server.

    Been there... have seen what can go wrong because it did... don't want to ever go through that again.

    In bulk, the Dev licenses are about $30-38 USD. Yes, you'd need a separate server but that's a very small price to pay to prevent Dev/Test accidents on the production server or against the production data itself.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • December 11, 2014 at 8:37 am

    #1764102

    Good gosh, don't do option 1. That will put additional stress on your production system, removing memory, fighting for CPU and disk access. No. Option 2 is pretty much the standard approach taken by most. You can get away with very reduced, VM, systems, so you won't need another copy of production to have a good test bed.

    ----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • December 11, 2014 at 8:57 am

    #1764114

    Thanks Guys for your feedback - I feel comfortable putting option 2 forward now.

    Many thanks

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply