Vergleicht Schemas und Daten - schnelle und klare Erfassung von Differenzen in Schemaobjekten und Tabellendaten über Instanzen Ihrer Datenbank:
Quickly and clearly see differences in schema objects and table data across instances of your database.
Generate update scripts without writing a single line of PL/SQL.
Take the complexity out of recording schema changes in Git, Subversion or Team Foundation Server.
Access the functionality of Schema Compare and Data Compare through the command line.
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.
Introduction to database continuous integration
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.
Keeps your database up to date
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.
Verifying database deployment scripts
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.
|116843||Deployment Suite for Oracle, 10 User, 1Y, EN, WIN, LIZ+MNT User Pack, Gesamtpreis||12||€11990,76||€14269,00|
|116844||Deployment Suite for Oracle, 10 User, 1Y, EN, WIN, MNT User Pack, Gesamtpreis||12||€2264,71||€2695,00|
|116845||Deployment Suite for Oracle, 10 User, 2Y, EN, WIN, LIZ+MNT User Pack, Gesamtpreis||24||€14379,83||€17112,00|
|116846||Deployment Suite for Oracle, 10 User, 2Y, EN, WIN, MNT User Pack, Gesamtpreis||24||€4525,21||€5385,00|
|116847||Deployment Suite for Oracle, 10 User, 3Y, EN, WIN, LIZ+MNT User Pack, Gesamtpreis||36||€16767,23||€19953,00|
|116848||Deployment Suite for Oracle, 10 User, 3Y, EN, WIN, MNT User Pack, Gesamtpreis||36||€6789,92||€8080,00|
|116849||Deployment Suite for Oracle, 5 User, 1Y, EN, WIN, LIZ+MNT User Pack, Gesamtpreis||12||€6373,95||€7585,00|
|116850||Deployment Suite for Oracle, 5 User, 1Y, EN, WIN, MNT User Pack, Gesamtpreis||12||€1204,20||€1433,00|
|116851||Deployment Suite for Oracle, 5 User, 2Y, EN, WIN, LIZ+MNT User Pack, Gesamtpreis||24||€7645,38||€9098,00|
|116852||Deployment Suite for Oracle, 5 User, 2Y, EN, WIN, MNT User Pack, Gesamtpreis||24||€2408,40||€2866,00|
|116853||Deployment Suite for Oracle, 5 User, 3Y, EN, WIN, LIZ+MNT User Pack, Gesamtpreis||36||€8915,97||€10610,00|
|116854||Deployment Suite for Oracle, 5 User, 3Y, EN, WIN, MNT User Pack, Gesamtpreis||36||€3615,13||€4302,00|
|152047||Deployment Suite for Oracle, 1 User, Lizenz inkl. 1 Jahr Maintenance eng. Win. User Pack||12||€1495,80||€1780,00|
|153757||Deployment Suite for Oracle, 1 User, 1 Jahr Maintenance Verlängerung eng. Win. User Pack||12||€283,19||€337,00|