SQL Server versioning on a complex existing scenario [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.

Closed 8 years ago.

Improve this question

I'm studying some scenarios and want some help with it.

We have a team with 68 developers. We all work on three web softwares and all of them are SQL Server based. We have today about 4 databases with setup data of our products, and about 5 types of other databases, to store client's data. These clients databases have mostly the same structure.

Our development and homologation environment are shared to all developers, that are scripting all day long, making changes on tables, stored procedures, etc.

The thing is we are having much trouble to guarantee that one can pass through development, to homologation, then to the production environment without any trouble, like, lost a piece of his work, caused by another developer that was working on the same object.

So, I know the Red Gate's solution, but it is very expensive to us right now, but it sure is the most adaptive and maybe the best solution of this kind on market right now. But I'm wondering if there´s no another solution, maybe using some softwares combined together, or maybe adopting a kind of process... Anyway, I would appreciate some directions because I'm kind of lost right now.

If anyone knows some fonts that I can research, it will be good too.

I have read somethings about this matter, that I found here on Stack Overflow, but they mostly said that the best thing is to use a local copy of the databases, but with my scenario I don't think that's a good option right now. Any ideas, guys? Thanks in advance!

Answer 1

What we are doing in our team (much smaller though, about 10 people working on the databases) is:

1. Everyone uses a local database to develop and do their daily job.
2. We use Visual Studio database projects to store the structure of the databases. Developers check in their changes in the same way as the code. All the merge conflicts are resolved in TFS which also gives us versioning.
3. We prepare the scripts to upgrade testing, staging and production environments from the database project nightly. We can do that at any time for any version though as the database structure is versioned and thus aligned with the code.

I hope you find this answer helpful in some way. I can elaborate more on specific points if you want more information.