tSQLt Objects / Source Control

kakins-tamus

We are using RedGate combined with SQL Test (tSQLt). In order to unit test, we install the framework on each database.

Is there a way to use the tSQLt framework in such a way where your unit tests and framework objects can reside in one central location which can then be used by multiple databases?

We are also using RedGate's SQL Source Control with TFS as our repository to track schema changes. These changes get promoted in the following environment order: Development --> Test --> Production.

Needless to say, the addition of the framework combined with the tests themselves represent large amount of new SQL objects (tables, stored procedures, etc) now in our databases. Ideally we would like these objects to reside only in Development and Test and avoid cluttering our production database. We could skip merging the tSQLt changes to Production, but then we would have unmerged changes sitting around in the Test environment's source control until the end of time.

Any thoughts on getting around this problem?

I also posted this question on StackOverflow here:
http://stackoverflow.com/questions/3687 ... ganization

macaskir

If you still want your tests in source control but don't want to promote them to the higher environments, that is the default behaviour in Redgate's DLM Automation Suite. You can either use one of the build server plugins (like TeamCity or TFS for build/test then Octopus Deploy for release) or do it all in PowerShell using SQL Release. https://documentation.red-gate.com/disp ... umentation

If you have a license for Redgate's SQL Toolbelt, you might already be licensed for the Automation tools (this is a change to previous licensing); http://www.red-gate.com/products/sql-de ... automation

(replied to this on the StackOverflow post as well)
regards
Richard (Redgate product manager)

kakins-tamus

Thanks again for your response macaskir. I responded to your comment on StackOverflow as well. I'll look into this.