1.11.8 - October 7th, 2015

Feature

• Display connection error when ReadyRoll cannot connect to development database (Details)

Fix

• Fix: Prevent infinite loop when error occurs when loading project (Details)

1.11.7 - September 22nd, 2015

Features

• Build performance improvements - We have made substantial improvements to the efficiency of the migration parser in ReadyRoll, resulting in faster builds and reduced memory usage. These changes provide a significant performance boost, particularly for larger projects. Here are a few benchmarks we have taken from 1.11.7, compared with the previous release:
  • Clean build performance - The amount of time it now takes to perform a  rebuild  of a customer’s ReadyRoll db project containing 19,000  Deploy-Change migrations .
    57 seconds - 20x faster (previously took ~19 minutes to complete)
  • Incremental build performance -  The amount of time it takes to perform a  build  of the above ReadyRoll db project, immediately after the  clean build  has been performed (i.e. all output artifacts are already up-to-date with project sources).
    7 seconds  - 13x faster (previously 1 minute 45 seconds)
    The majority of the time is now spent querying the SQL Server database instance to determine if there are any migrations pending deployment, rather than in the scanning of the db project itself.

• Performance on smaller projects - The changes in this release will primarily benefit database projects with more than 1,000 Deploy-Change migrations, however smaller projects should also see an improvement as well. We performed some tests on a project containing 300 migrations. The performance improvement was less significant but still noticeable: from a previous build time of 5 seconds down to 4 seconds.
  Tests were performed using VS2015 on a dual-core i7-5600 with 8GB RAM and SSD storage.
• DBSync tool performance improvements - The improvements to the build engine actually have a flow-on effect to the DBSync tool, as much of the migration parsing code is shared between the two areas of the product. You may notice that the tool is more responsive, and also that refresh/import performance is generally a lot better (particularly with larger projects).
  • Deploy-Change import performance - We have made some improvements to the DBSync tool that will make the process of importing a large number (over 10,000) of database objects into Deploy-Change migrations significantly faster. For the vast majority of databases, the initial import of Deploy-Change migrations should now complete in less than 30 seconds, whereas previously this process could take longer than 10 minutes.
    Note: Beyond the initial creation of the Deploy-Change migrations, there is still a performance bottleneck at the stage of the process where the files are added to the Visual Studio .sqlproj project file (for larger projects, this can still take a number of minutes to complete). We plan to improve the performance of this part of the process in a later release.
  • Responsiveness of DBSync tool with larger projects - Previously, an extended delay was encountered upon opening a project containing a large number of migrations. The delay was caused by the DBSync tool, which was attempting to parse the entire contents of the project migrations upon load (rather than just loading metadata and performing a checksum on the files). The DBSync tool should now be responsive within 20 seconds of opening even a very large database project (20,000 or more Deploy-Change migrations).
• Support for BULK INSERT operations - One of the most efficient methods for loading data into a table is to save a set of seed data to a flat file and use the BULK INSERTT-SQL statement to upload the data. However, including a seed data file in a ReadyRoll project has previously not been possible, due to the fact that BULK INSERT requires an absolute path to be specified for the input file. ReadyRoll does support synchronization of static data, however this is only really optimized for smaller data sets (i.e. fewer than 10,000 rows).
  ReadyRoll 1.11.7 introduces a new system  that allows you to fully qualify the path to a flat file, allowing you to rapidly seed database tables with vast amounts of data by including the flat file as part of your deployment package.

How support for BULK INSERT operations works

Add a flat file to the root of your ReadyRoll database project, and set the Copy to Output Directory property to Copy always. This ensures that the file is included in your Octopus-compatible NuGet .nupkg file when your project is packaged for deployment.

Add a blank new  Deploy-Once migration script to the project and specify the $(DeployPath) variable as part of the input filename in a BULK INSERT statement, e.g.

BULK INSERT [Production].[TransactionHistory]  
 FROM '$(DeployPath)TransactionHistoryData.csv'  
 WITH (FIELDTERMINATOR = ',', FIRSTROW = 2);

When you deploy the project in Visual Studio, you’ll notice that the variable is resolved to the directory path of the .sqlproj file:

C:\source\samples\AdventureWorks\

If you package the project and subsequently deploy the database using Octopus, the $(DeployPath) variable will instead resolve to the folder where the package was extracted to:

C:\Octopus\Applications\MyProject\AdventureWorks.Database\1.0.2.106\

By using a flat file to populate your database schema, you can insert thousands of rows into your tables in seconds.

Read more about this feature in the documentation

Fix

• SQL Azure database deployment issue resolved - ReadyRoll has had support for deploying to SQL Azure-hosted databases since version 1.9.
  The package scripts that ReadyRoll generates contain USE statements, which are typically only required for on-premise instances of SQL Server, as SQL Azure automatically connects to the given target database upon deployment. In fact, it expressly forbids switching of database context once the connection has been made, however the USE statements are typically ignored if the target database is the same as the current context (as is the case with ReadyRoll deployment packages).
  However, for some customers, the inclusion of USE statements in the package deployment script was problematic. For this reason, ReadyRoll now excludes all USE statements from SQLCMD packages, and instead includes a database context check prior to performing a deployment. (Details)

1.11.6 - August 31st, 2015

Features

• Support connecting to SQL Server 2016 CTP instances (Details)
• Upgrade to OctoPack 3.0.43 (Details)

Fixes

• Selecting “Azure SQL Database V12” as target platform results in a build error. (Details)
• Added reporting of anonymous usage statistics - option to disable during installation process
• Allow additional files to be included in Octopus packages (Details)

1.11.4 - August 20th, 2015

Feature

• New application/project type icon 

Fixes

• Filter rules for UDF, Data Types, Ddl Triggers are being ignored since upgrade to SQL Compare SDK (Details)
• T-SQL scripts generated with the SQL Server Object Explorer are not being added to the ReadyRoll project (Details)

1.11.3 - August 6th, 2015

• Large databases cause the DBSync tool to freeze at “Sorting results…” stage. (Details)
• Out of memory error when attempting to Import databases with with over 10k DB objects (Details)
• Out of memory error when attempting to Package projects with over 10k DB objects (Details)
• Reverting security objects (Users, Roles, Schemas) results in “Script is empty” error (Details)
• ReadyRoll uses incorrect local db instance in VS2013 (Details)
• Error in databases with case-sensitive collation: The multi-part identifier “tab.CONSTRAINT_TYPE” could not be bound. (Details)

1.11.2 - June 30th, 2015

• Static data Import - Data is duplicated in generated script (Details)
• Static data Import - Differences in timestamp columns appearing (Details)
• DBSync tool does not display change summary alongside schema objects (Details)
• Error in diff preview window:  FOR XML EXPLICIT and RAW modes currently do not support addressing binary data(Details)

Please note that this release contains an updated EULA.

1.11.1 - June 22nd, 2015

• “Cannot find SQLCMD.exe” error during VS build/deployment (Details)
• Upon project creation, migration objects appear in list of pending changes (Details)
• Primary Key violation error on [__MigrationLog] table during deployment (Details)
• Cancel button in DBSync tool causes unexpected behavior during Import (Details)
• Excess SET ARITHABORT / ANSI_NULLs etc statements included in imported scripts (Details)

1.11.0 - June 5th, 2015

Our customers regularly tell us that, although they love the migration-based deployment style of ReadyRoll, our Visual Studio extension could do a better job at generating T-SQL scripts. Some customers even resort to using an external schema comparison tool and then copy+pasting the sync script into their ReaydRoll project.

This release swaps out the script generation engine within the ReadyRoll DBSync tool-window in favor of Redgate's  SQL Compare  engine.

Note that this does not affect the method of deployment to your target environments; this change only applies to design-time script generation and migrations continue to be used for 100% of your releases.

Apart from generating smarter synchronization scripts, using the SQL Compare engine has some other benefits:

• Performance of the DBSync tool-window is improved, particularly after caching of the schema has taken place (i.e. upon repeated Import/View Pending Changes operations).
• You can now organise your Deploy-Change migrations however you like. Previously, you had to adhere to a strict file naming and folder structure convention of [ObjectType]\[Schema].[ObjectName].sql. Now you can re-organise the files under separate schema folders, use your own file naming style, or even mix multiple related objects within the one file.
• When importing Deploy-Change migrations, any custom logic within your script files will be preserved. For example, say you have a table constraint that depends on a user-defined function object. You can now (manually) insert the ALTER TABLE [foo] DROP / CREATE CONSTRAINT logic within the DC migration in order to deploy the function and constraint together in one atomic operation. If you subsequently import a change to that function from SQL Management Studio, the constraint logic would be preserved in the file (previously the constraint logic would be lost during the Import operation).

Fixes

• The Offline Schema Model contains invalid T-SQL in Table definitions (particular in WITH clauses) as well as duplication of table-bound objects such as keys and indexes. Resolved through replacement of script generation engine
• Deployment preview report does not show schema differences (Details)
• Octopus deployment previews. Doesn’t work if ReleaseNotes element is present in NuSpec. (Details)
• ReadyRoll project settings not appearing when Properties opened via solution explorer (Details)