Application DBA, SQL, DevOps
Until a few years ago, it was common to have the database development lifecycle completely separate from the main application development lifecycle. While the app dev team enjoyed modern lifecycle techniques, the DBAs find themselves inventing their own solutions for things that already come pre-packaged and ready-to-use for the application developers next door. Source control? Let’s use a file server or the DBA’s PC. Version history? Maybe in my Dropbox somewhere. Unit tests? Not in our domain. Continuous integration/deployment? Never heard of it.
As a result, both DBA and app dev teams find themselves fighting to “align” between database schemas and application versions. In the end, we are left with poor communication between the application and database teams, longer development cycles, longer or even non-existent testing cycles, many errors during deployment (most of which are sometimes quite embarrassing, other times downright dangerous), and more.
Meet SSDT (SQL Server Data Tools), that comes with the SQL Server Database Project as an answer to all of the problems above. In this session, I will be presenting the methodology behind SSDT, the various SSDT tooling that we get for implementing that methodology, how to solve common issues and edge cases, and we will also learn important lessons in source control, Git flows, and CI/CD pipelines.
Why I Want to Present This Session:
This webinar is based on my real-world experience of implementing source control methodologies and CI/CD for SQL Server database, using the Microsoft SSDT environment. My experience comes with answers for all the common fears and objections coming from naysayers, for common problems while starting with SSDT for the first time, and for various problematic edge cases.
If you ask me, every self-respecting SQL Server DBA must be familiar with this tool and its methodologies, and why it can be beneficial for every organization. We all know the database is a critical element of your software product. It’s high time for that fact to be reflected in your database development lifecycle!