January 14, 2014 at 1:42 pm
I have been placed in an admin role where I'm the only dba/db developer and I have 5 programmers on my team as well. Right now I'm seeing inconsistancies between tables on the dev enviroment where they should be the same...ie dev_box database A table mytable has 5 columns and dev_box database B mytable has 7. But these two tables are supposed to be the same. Is there a good source as to they type of policies to put in place to help keep things organized? I've been thinking of the following:
1. If a developer needs to change a table structure they send me the script file, I check it to ensure its correct, I execute it, archive it in TFS with the date and time so that when it comes time to roll out I can roll them out in the same order they were changed in dev.
2. Creating userroles without permission to make changes to the table structure but allowing them to exe inserts, updates, and deletes.
any more ideas or suggestions would be appreciated
January 15, 2014 at 3:47 am
I wrote several chapters in a book called, SQL Server Team-Based Development[/url]. Now, some of the work is WAY out of date since the technology has moved on quite a bit since I wrote the book originally. But the concepts are absolutely still valid. Check it out and see where it can help. It's a free download. In general, I aim towards treating databases the same way everyone treats code, all builds and deployments come from source control and only source control. Any and all changes made outside of source control can, and should be, lost. Personally, I'd aim towards getting your developers their own sandbox servers where they can do anything they want, but have an integration point where any changes made (all through source control) can be validated.
I wouldn't suggest getting in front of them and reviewing every script that they do. They're going to get things right for most small things. And, as long as everything is done through source control, you can always rollback to previous versions. There's more to it, but that's a start.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 15, 2014 at 3:50 am
One more, we recorded a two-part webinar[/url] for Red Gate (who I now work for, didn't when I wrote that book) on deployments. Part two is primarily around Red Gate tools, so you might want to skip it, but Part one is nothing but a discussion around the kind of mechanisms you're looking at.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply