How to Tell if You Have a Development Environment

SQL Server

Take my three question survey…

Slide1 Slide2 Slide3

Brent Says: SQL Server Developer Edition licensing is crazy cheap, and it has no per-core licensing fees. I like taking the oldest server I have with a huge number of cores, something that doesn’t make licensing sense for any other purpose, and throwing Developer Edition on there.

Previous Post
Overheard in Performance Tuning Training Class
Next Post
Ten Ways to Tell if Your SQL Server is a Clown Car

25 Comments. Leave new

  • I guess I should consider myself lucky 🙂

    We have the following environments besides production

    Dev-Integration (this is for the other apps that connect to dev but we don’t push changes to this ad-hoc but twice a week)
    2 Test environment (1 is always live..this way if restores are being done..test is not down at any time)

    Except for Dev..everything else is built from SVN by an automated process

  • Dave Wentzel
    March 11, 2015 8:31 am

    re Question 1…every server is a prod server to someone. I worked in a shop where the DBA needed to do maintenance on a dev server during the day because she didn’t want to work at night. That meant 700 developers now had the perfect excuse to youtube all day.

    • Mike Henderson
      March 11, 2015 9:09 am

      That’s a nice trick that DBA pulled off.

      I used to have to restore a production backup to the development environment after a monthly release. It had to be from the latest backup with the new release changes. The backup finished at midnight, and I had to have the development environment available when the developers rolled in at 8:00 am.

      Over time I automated most of the process, but I was still up at 4:00 am checking to make sure nothing blew up.

    • Kendra Little
      March 11, 2015 9:17 am

      I get your point — it can absolutely be expensive to have development servers offline. I do think the terms are still useful because they tend to have very different requirements for recovery point objective, permissions, and data content. But I totally agree that in large software development shops, Recovery Time Objective and availability of development databases is critical!

  • Another caveat, since I recently read the licensing docs on Team Foundation Server: if a SQL Server is hosting TFS data, Microsoft *never* considers it a Development environment. This leads to all kinds of fun confusion if your SysOps never lets your developers touch a production server and/or thinks dev servers don’t need backups.

    • Kendra Little
      March 11, 2015 9:21 am

      Haha, yeah– for many companies, their source code is their most valuable intellectual property! Critical line of business application, not a dev environment. Great point.

    • Raul Gonzalez
      March 11, 2015 1:01 pm

      Also happened to me, the big fun was when building the new TFS on standard edition (fully licensed) some databases didn’t want to be restored as they had compression on some indexes.

      Had to get the old server, remove compression by rebuilding those and then backup/restore again.

      All good at the end.

  • I’m in an environment where developers are not allowed any access to production data. The reason I’m given for using garbage data in development is “you’ll develop better troubleshooting skills.” Do you have any suggestions on how to convince management to allow cleaned production data into development?

  • Now that we have defined some of the limits between Dev and Production… what are the questions for QA Servers?

    • QA to me falls into a fun location, because it can be treated as a DEV environment, but if done right, will never be refreshed from Production. Here is the logic:

      In the beginning of the testing the database should be like production was right after the last roll-out.

      As testing goes on the QA database will drift from what production is to what it will be, with the expectation that as items fail they are rolled back out of the QA DB (developers should not be fixing things in this environment). (Everyone creates a roll back plan correct?) 🙂

      The day before release, the environment should look like what production will be the next day.
      Rinse and repeat…

      Now we all know that this is a true pipe dream, you will need to refresh this database, but it should only be in once in a blue moon. 🙂

      Watching the QA and Developers minds get blown when you walk through that simple logic is hilarious in the least… 🙂

  • Raul Gonzalez
    March 11, 2015 1:05 pm

    “Developer Edition licensing is crazy cheap” indeed it is, but I wouldn’t recommend it as developers are prone to use “Enterprise only” features and get the big crush when deploying to your affordable Standard Edition in production…

    My company doesn’t have to pay license unless the server is production, so I get same edition for all environments just in case.

  • I once worked for a company where we had PROD, UAT, DEV and a masked prod copy (for support) …. all across separate instances of SQL. It worked really well until we found that all 4 instances were actually on the same cluster of servers (2 in total active\passive) and that if a failure occurred the performance was so bad the application became unusable in any of the 4 environments. That was a fun day explaining that to the client….

    • Typed my comment too fast! The setup was PROD on node 1 and UAT\DEV\Prod Copy on node 2. Windows could move the roles as needed, but if all the roles ended up together (monthly patching anyone?), then performance turned sour!


Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.