Published 09 March 2018
This roadmap covers a range of ideas at differing stages of development. As with all roadmaps, the content is fluid, estimated delivery times are subject to change, and in some cases features will pivot and even may be removed entirely. We believe strongly in working closely with our customers to evolve our solution, and therefore we encourage feedback on all aspects of the roadmap, including suggestions on what we should work on next. You are welcome to email new ideas directly to the Product Manager or alternatively suggest/vote on ideas on our UserVoice site.
In the table below, the icons represent Schema Compare for Oracle, Data Compare for Oracle, Source Control for Oracle, and represents the automated build and release solution available exclusively as part of the Deployment Suite for Oracle.
Support for migrations-based deployments - Early Access Program
Currently, the Redgate Oracle solution uses the "state-based" deployment methodology. The desired state of the database is stored in version control and compared to the target database at deployment time to generate the deployment script. This model was chosen to provide the lowest overhead for development teams.
The state-based model works very effectively for the vast majority of changes, but there are a small number of changes that can't be inferred by a comparison engine, such as adding NOT NULL columns without a default, column/table splits/renames, transactional data updates, and other "complex" refactorings. If these changes occur, the deployment script generated by the state-based approach needs manual customization before running. If these types of changes are infrequent, this may be acceptable and using Pre/Post SQL scripts in your deployment pipeline might be fine. If these types of changes are common, it becomes a chore. This is where the migrations-based deployment methodology is arguably better suited. In this migrations model, a "migration script" (think of it as a micro-deployment script for a changeset) is saved on each checkin and stored alongside the desired state in version control. Crucially these scripts can be customized at development-time. Upon deployment, instead of generating a new script by comparing states, the deployment script is constructed from these migration scripts. A log table in the target databases keeps track of which scripts have already been applied to that database, so they only run once and don't have to be written idempotently.
One downside to the migrations-based approach is the number of migrations scripts that can be generated. Our solution will feature "Programmable Objects" to treat procedures, functions, views and any "code" objects that don't impact data differently to structural changes. Instead of creating a new migration script when a programmable object is modified, the tool will simply update the "state model" and use this for the deployment. This approach vastly reduces the number of migration scripts created as part of development.
Our solution will be based on the same technology as our current SQL Server technology, which is very mature and trusted.
Please contact us if you are interested.
Expected time-frame for release: H2 2019
Linux-compatible command lines - Release Candidate Available
The use of Linux build agents (or "slaves") as part of an automated build and release process is increasing. Redgate's command lines are currently Windows-only, which necessitates separate Windows-based build agents to be spun up. With this Release Candidate, you can continue to user your existing Linux agents.
Expected time-frame for release: H2 2019
Static code analysis - Preview Available
Code analysis will reduce the number of 'code smells' that creep into your database builds and help maintain best practices, especially if database changes are made by multiple team members. This feature, implemented as a command line, would provide:
Expected time-frame for release: H2 2019
Find Invalid Objects
It can be important to understand which objects are in an invalid (uncompiled) state. This feature, implemented as a command line, would provide:
Please contact us if you are interested in finding out more.
Expected time-frame: 2020
Improved release report artifact
Schema Compare for Oracle can output a basic change report that can be used as a review/approval artifact in a release process. An improved report will include difference highlighting and deployment warnings.
Expected time-frame for release: H1 2020
On occasion it may be desirable to run custom SQL before or after a deployment script, for example to configure server configuration settings, or to perform custom data motion. One solution is to adopt a migrations-based approach, but for teams that prefer the state-based approach, using pre/post-scripts is a pragmatic alternative.
These scripts would be configurable in Source Control for Oracle, stored in a "CustomScripts" sub folder. Schema Compare would recognize the existence of these files and run them upon deployment.
Expected time-frame for release: 2020
Making the creation of multi-schema projects simpler
In Source Control for Oracle, the process of adding multiple schemas is less than optimal as described in this UserVoice post. Similarly, adding a new schema to an existing project isn't possible, requiring the entire project to be recreated from scratch.
Expected time-frame for release: 2019/2020
Better support for Shared Development Databases
The pros and cons of shared vs dedicated development database models are discussed in our FAQs. We support both models. For the Shared Development Database model, we already have Object Locking (as of Source Control for Oracle v2.0) to ensure your changes aren't accidentally overwritten.
We're considering adding a "last changed by" column on checkin to help ensure that you checkin the correct changes that you have made (and not a change that someone else made, since these show up since you're all working on the same database).
What else can we do to make working on a shared development database even easier? Or, how can we make it super easy to provision dedicated environments per developer or per feature/release branches, if this is the better way for you to go?
Status: Need more user feedback. Please contact us if you are interested.
SQL Developer or other IDE integration
An advantage of Source Control for Oracle's "connected" development paradigm, where changes to a development instance are detected and offered for checkin, is that all Oracle IDEs are "supported". It doesn't matter where or how changes are made. The Source Control for Oracle icon in the Windows Task Bar will change when a difference is detected, alerting the end user that there is a pending change to commit.
Deeper integration with SQL Developer (or other IDEs) would mean that this notification is even closer to the context of the work being done.
Status: Need more user feedback. Please contact us if you are interested..
Note: The above list includes headline features and excludes improvements such as new object types and platform support.
What else should we be doing?
Previously shipped features
In the table below, Deployment Suite for Oracle.represents the automated build and release solution available exclusively as part of the
Version 5.2.0 - December 21st, 2018
It is already possible to filter down the list of objects in Schema Compare for Oracle and Source Control for Oracle. However, this filter applies after the tool reads the full schema, which, if large, can be time-consuming. The new Ignore Objects feature, available across the Deployment Suite for Oracle, allows schema objects that are known to be irrelevant to be explicitly excluded from the outset, which can dramatically improve performance.
Version 5.0.0 - October 16th, 2018
Added ability to deploy static data held in source control.
Source Control for Oracle v4 allowed static data to be stored in version control in csv format, which enables audit and version history as well as the sharing of changes among developers. Static data deployment takes this a step further and allows the versioned static data to be deployed alongside schema changes.
The /comparison:includeSourceTables command line switch has been added to the Data Compare for Oracle command line for cases where the target schema structure is different at the time of comparison (this would occur if you are generating schema and data deployment scripts ahead of the actual deployment step).
|The project refresh mechanism has been optimized as follows:|
"Preview" features were previously only available in separately downloadable builds. Now preview features can be tried by simply toggling a feature flag in the released build. Find out more.
Version 4.0.8 - April 4th, 2018
Extended NESTED TABLES comparison.
Support .NET 4.6.1 framework.
Improved "Tables & Views" tab dialog, with support to map tables of different names. See documentation.
Show differences to the sco.exe command line tool console output in verbose mode.
Version 4.0.6 - December 5th, 2017
Version 4.0.5- November 22nd, 2017
Static data can now be checked in to version control. Data Compare for Oracle v5 is expected to include an accompanying feature to deploy these static data changes against a target database.
Version 4.0.2 - September 13th, 2017
Version 4.0.0 - July 27th, 2017
OC-898: Support identity columns for non-dba user