How to improve and extend SQL Server Data 1
Transcription
How to improve and extend SQL Server Data 1
1 How to improve and extend SQL Server Data Tools with Red Gate tools 2 Summary Microsoft SQL Server Data Tools (SSDT) help developers use best practices, such as Agile development, for databases. However, SSDT is tightly linked with other Microsoft technologies. It also enforces ways of working which may not suit all teams. Red Gate’s tools extend SSDT so teams can use non-Microsoft technologies, and choose how they prefer to work. SSDT only Red Gate tools + SSDT Develop in Visual Studio Develop in Visual Studio or SQL Server Management Studio, the most popular platform for SQL Server development Works best if you use Microsoft's Team Foundation Server (TFS) for version control Works well with proprietary or open source version control systems, including TFS, Subversion, Git, Mercurial, & Vault Requires developers to work with individual copies of a database Lets developers work with an individual copy, or a single, shared database, which is simpler if the production database is hard to replicate Version control for schema changes only Version control for schema changes and static data changes Limited support for automated deployment Allows deployment straight from version control, and automatically includes migration scripts to safely handle complex changes 3 The background Changes in the software development landscape, such as the rise of Agile, are creating pressure to deliver software faster. There are great tools to help with this for applications, but databases have lagged behind. To meet this need in database development, Microsoft introduced SQL Server Data Tools (SSDT) and Database Projects. These offer a simple project structure that lets application developers build and modify database schemas in Visual Studio alongside the rest of their code. They’re also tightly integrated with Team Foundation Server (TFS), which begins to simplify deployment. If you’ve invested in Visual Studio and TFS, SSDT can go a long way to improving change management for new projects. But on its own it doesn’t suit all teams, because it enforces certain ways of working. By using Red Gate tools alongside SSDT, you can work with a wider range of projects and configurations, continue to develop existing codebases without significant refactoring, and improve automation and deployment. Flexible tooling to work the way you want SSDT delivers the most benefit if development teams work in a few fixed ways: • in Visual Studio • with TFS • with each developer having a sandboxed database instance The SQL Developer Bundle gives you extra flexibility, and means you don’t need to change the way your developers and your organization work. Visual Studio or SQL Server Management Studio? Using the best tools for the job Development teams are often formed from a combination of application and database developers. Application developers, or those who regularly work on a combination of application and database code, may like to work in Visual Studio. However, database developers may strongly prefer to work in SQL Server Management Studio (SSMS), as it better supports 4 SQL development. It also has a wealth of add-ins to make development easier. SQL Prompt and SQL Search, for example, integrate with SSMS to improve productivity. SQL Test enables T-SQL unit testing, based around the popular tSQLt open source framework. Used on its own, SSDT requires all developers to work in Visual Studio. Red Gate tools allow development to happen across the two environments, helping development teams work efficiently and without disruption. SQL Source Control connects SSMS with your source control repository, allowing changes made in SSMS to be shared with Visual Studio users, and vice versa. You team can work how they prefer – against a live database or on scripts in Visual Studio. Version control systems SQL Source Control supports TFS, Subversion, Git, Mercurial, Vault, and any source control system with a command line interface, so your SSDT implementation doesn’t have to mean changing version control system. You can get the benefit whether you’re using TFS (recommended with SSDT) or any other system. Local and shared databases In SSDT, changes are made to SQL scripts, and then deployed to a local database for testing. This could result in changes not being deployed to a realistic environment very frequently, but it follows a model similar to application source control and many teams like it. Others prefer to work under a shared model, where multiple developers modify the same database. This often occurs when teams have environments that are hard to replicate realistically. Red Gate tools support both shared and individual development databases. Again, this extends the capability of SSDT to meet the specific needs of your team. Getting the data right With SQL Source Control you can source control and compare reference data (static data, lookup data, and configuration data). SSDT doesn’t support static data – it’s focused on schema changes. But lookup data in particular can change with your business logic, so it’s good to have it tied to your database development. SQL Source Control bridges the gap, letting you check static data into source control, so it’s versioned alongside schema changes, and you can include it automatically with deployments. 5 Red Gate also provides highly customizable data generation, through SQL Data Generator. This means you can test your changes on realistic data when production data is not available, for example, if it’s sensitive customer information or financial data. Adding this capacity to SSDT enables more accurate testing, and lets you include reference data in automated deployments, removing the need for post-deployment changes. Robust, repeatable deployment and continuous integration In SSDT you can deploy changes to a local database instance from Visual Studio, or create a DACPAC that can be deployed via SSMS or SQLPackage. This works well, but can be improved. In particular, Red Gate tools help you increase reliability and ease of automation when you would need customization and pre- or post-deployment scripts. Most commonly, that’s when schema changes require data manipulation, such as with table and column splits, merges and renames, data format conversion, or adding NOT NULL columns without a default. Comparison tooling can’t guess the intent of your changes, so you need to add scripts as a workaround. It’s messy and less robust for automation. Red Gate tools can automatically incorporate migration scripts when you deploy schema changes. Your deployment scripts can therefore be run automatically (for example in continuous integration) without needing manual intervention; or, you can handle them manually, reviewing a whole deployment for QA, without fear of data loss or the need to review multiple scripts without context. The command line versions of SQL Compare and SQL Data Compare can be used to automate deployments from source control, so you can set up continuous integration for your database changes, whatever your source control and build system. For more information, see our whitepaper, Continuous integration for databases using Red Gate tools Whitepaper Continuous integration for databases using Red Gate tools A technical overview 6 your changes SQL Compare and SQL Data Compare are the market leading, industry-standard tools for comparing and deploying SQL Server changes. In fact, 70% of the Fortune 100 use SQL Compare. These tools let you see database changes quickly, easily, and in detail, as well as letting you create reports. Unlike deploying with a DACPAC, you can review and edit the deployment scripts generated by SQL Compare and SQL Data Compare, or use them to verify the state of your environment after an automated deployment. The reporting functionality can itself be automated via the command line interface, giving you a clear history of what schema changes have been made. Project is being deployed reliably to each environment, without error or data loss. Conclusion If you’re using Database Projects and SQL Server Data Tools to make your database changes, Red Gate tools can help you minimize the disruption to your team, and improve the reliability of automation and deployment. Developers who prefer to work on SQL scripts in Visual Studio can work side by side with those working connected to a live SQL Server database in SQL Server Management Studio. control. The Continuous integration for databases using Red Gate tools Whitepaper 7 All the Red Gate tools outlined in this document are available as a free trial, or you can get in touch to arrange a demo. SQL SOURCE CONTROL Helps maintain database schema and data in a source control system within SQL Server Management Studio Allows for the creation of custom migration scripts which are saved to source control SQL COMPARE & SQL DATA COMPARE Create a database from source files in version control Generate schema and data deployment scripts Validate that two databases are identical Generate pre/post-deployment reports for troubleshooting SQL TEST Allows developers to easily create, run, and manage tSQLt unit tests on databases SQL DOC Generates the latest database documentation automatically as part of your CI process SQL PROMPT & SQL SEARCH Productivity plug-ins for SQL Server Management Studio SQL Prompt provides code completion, formatting, and help with refactoring SQL Search finds fragments of SQL inside stored procedures, functions, views, and more SQL DATA GENERATOR Generates realistic test data based on your existing schema SQL AUTOMATION PACK Command line versions of the tools in the SQL Developer Bundle