People who wish to manage and test T-SQL changes more reliably and efficiently, regardless of role.
This isn’t the dark ages any more. You’ve learned that you need to put your database in source control and you’re competent with source control systems like TFS or Git. You’ve also learned how to express your database in script form using a tool like SSDT, DbUp or Redgate.
However, you still haven’t written as many automated tests as you know you should and you aren’t convinced you’re going about it the right way. You haven’t looked at the build functionality in VSTS yet or gotten to grips with build servers like TeamCity or Jenkins, and even if you have you aren’t sure how the process should work for SQL Server builds and tests.
In this session I’ll explain how to use tSQLt to build a suite of automated tests to give you confidence in the quality of your code. Then I’ll talk through various ways to automate your database builds and run those tests on some schedule or trigger. I’ll also discuss the pros and cons of various different approaches so that you can understand which approach would suit your teams and projects.
Why I Want to Present This Session:
I see so many organisations managing and testing their T-SQL changes poorly. This creates cultural problems, finger pointing, blame. I makes it very difficult for us to deliver updates with the pace and quality our businesses desire. It makes it very difficult to adopt DevOps.
I love SQL Server. But given that we are so poor at managing relational database changes, many people see the database as a bottleneck. They move data logic into the application because sprocs are seen as evil, they drop relational databases for NoSQL alternatives and use DevOps or Continuous Delivery as the argument, rather than the suitability of the particular NoSQL database for storing the particular data in question. This means there are less opportunities to work with SQL Server – and some people see me as a dinosaur.
I want to do my part to bust the myth that SQL Server is impossible to test properly. I want to stop databases being the bottleneck in releasing software reliably.
Latest posts by Alex Yates (see all)
- Getting CI right for SQL Server - March 21, 2017
- DevOps 101 for data professionals – how your jobs will change - November 25, 2016