Source Control for Oracle
Regular price: $369
Schema Compare for Oracle
Regular price: $495
Data Compare for Oracle
Regular price: $495
per userBuy now
“This really is the best tool possible to make database upgrades between different environments.
I work at a bank and the rules here are very restrictive. The only way to ensure that we deploy with zero errors is to use Schema Compare for Oracle”
“Redgate's Schema Compare is by far the best schema comparison tool on the market. It now takes just 45 seconds for me to compare 6,000 objects in different instances of my database.
This used to take 45 minutes in Oracle SQL Developer!”
“We plan to integrate Data Compare for Oracle in our nightly builds. At the moment, all our data related changes have to be scripted manually, which is error prone and not very productive.
With Data Compare for Oracle, we can easily compare the data in two different database builds and generate the synchronization script. It's going to save at least an hour of development time each week – and stop me going grey so quickly.”
“Redgate's Schema Compare for Oracle accurately compared Peoplesoft Financials in 38 minutes. Embarcadero completed the same job in over 12 hours, and we simply couldn't get Toad's schema compare tool in their DBA suite to even finish the job, it would just error out.”
Continuous integration (CI) is the process of ensuring that all code and related resources in a development project are integrated regularly and tested by an automated build system.
Code changes are checked into source control, triggering an automated build with unit tests and early feedback in the form of errors returned. A stable current build is consistently available, and if a build fails, it can be fixed rapidly and re-tested.
If you want to get started with continuous integration for your database, you'll need the SQL Automation Pack.
A CI server uses a build script to execute a series of commands that build an application. Generally, these commands clean directories, run a compiler on source code, and execute unit tests. However, for applications that rely on a database back-end, build scripts can be extended to perform additional tasks such as creating and updating a database.
The diagram illustrates a typical integration process. The automated continuous integration process begins each time the server detects a change committed to source control by the development team.
Continuous integration ensures that if at any stage a process fails, the ‘build' is deemed broken and developers are alerted immediately.
Database code is code, and should therefore be treated in the same way as your application code. However, the principal difficulty underlying continuous integration for databases is the lack of a simple way to keep a database in source control and deploy it to a target server.
The database is unlike application code in as much as it contains a state that needs to be preserved after an upgrade. Where a production database already exists, DML and DDL queries modify the state of a database. Unlike application code, there is no source code to compile. Deployment therefore relies on creating upgrade scripts.
The lack of database source code makes it difficult to maintain a current, stable version in source control. Creation scripts can be checked into the source control repository, but despite their importance, the disciplined creation and on-going maintenance of these scripts is not often considered a core part of the database lifecycle.
Where changes are deployed to an existing database, all differences and dependencies must be accounted for. In some production deployments, this involves multiple targets with different schemas and data. The manual process is time consuming, prone to errors, and one that should not be left unresolved at the end of the project cycle.
Databases may figure in your CI process because the application code requires a database to function correctly. The database schema version corresponds to an analogous application code version. Any changes to the application code or the database structure could, in theory, break the system. Consequently, they should trigger the CI process.
Once a database is maintained in source control, Redgate tools can build a clean database from its source files to accompany the application build.
If you already have internal test databases that need to match the development databases, you can keep them up to date with the latest version, using continuous integration.
Developers get immediate feedback on each change they commit to the database scripts. If the build fails, they know exactly which change caused it to fail.
From our webinars with Oracle experts, to the independent community at All Things Oracle, we aim to give you the best resources on a whole host of Oracle topics.
Check out All Things Oracle for content from the leading names in the Oracle community.Visit All Things Oracle