Take my three question survey…
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.
25 Comments. Leave new
I guess I should consider myself lucky 🙂
We have the following environments besides production
Dev
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)
Staging
Except for Dev..everything else is built from SVN by an automated process
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.
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.
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.
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.
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.
Why Standard Edition? I thought TFS included whatever licensing it required?
Kendra, you made me pull out the licensing whitepaper. My OP is a little confused. The trick MSFT don’t want you pulling is licensing your TFS server’s OS using MSDN – for that you need a fully licensed Windows.
And rights to one instance of SQL Server 2014 *Standard* are included with the TFS license. Hence Raul’s problem described above.
Oh, got it! I thought the comment was that TFS shipped with compressed indexes, which implied to me that it would also included a license to support that. But sounds like not at all.
Back when I worked with TFS, I also worked at Microsoft, so we had the luxury of just using Enterprise on all the things.
Well, licensing a TFS server to Enterprise it’s too much, even more considering you can have an Express version
https://msdn.microsoft.com/en-us/library/dd631889.aspx
TFS shipping with compressed indexes would have been evil. I bet someone compressed Raul’s previous TFS due to lack of disk space, which as we know is kind of pointless.
TFS also ships with multidimensional cubes, and those are always fun.
I’m not sure if I want to know if all the stored procedures are still encrypted.
On the other hand I’m no expert on licensing 🙂
but just made up an answer for you being always nice
http://stackoverflow.com/questions/19439523/msdn-licensing-for-use-of-sql-server-2012-and-tfs-2013
Kendra: Yup, the procs are encrypted.
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?
If you don’t have production-sized data in dev you can run into a number of problems. On quick example: You might deploy a proc to prod that ran great on 5 records but takes 36 hours against 50 million.
We recently acquired a data masking tool for this purpose (called DataMasker, strangely enough). It was not cheap, but we currently have production PII/PHI in dev so we had the liability removal as a selling point.
We anonymise all the data as much as possible before putting into Dev.
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… 🙂
“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 agree. If you can get all developers and testers MSDN Subscriptions it’s much safer to use the same edition across all environments.
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!