Technology partners
Redgate implementation for database DevOps
Interkey implements Redgate’s tooling for organisations in Saudi Arabia that want database changes delivered the way application changes already are: from version control, through a pipeline, with checks before deployment and a rehearsed reverse.
In short
What Interkey delivers with Redgate
Redgate makes the tooling Interkey implements when a database delivery practice needs its tools: Flyway for versioned migrations across the mainstream relational platforms, and the SQL Server toolset for comparison, source control and monitoring of an estate built on that engine. Interkey’s work is putting those tools into a pipeline that already exists, retrofitting the change patterns that make automation safe, and handing over a practice the team can run.
This page is not the practice. The practice — why the sequence is not negotiable, why rollback is where the discipline is decided, what finished looks like — is on the database DevOps page, and that page is deliberately indifferent to tooling because a tool does not fix a team whose changes require an outage. This page is what changes when the tooling is Redgate’s: which tool carries which step, and what the implementation actually involves.
The honest framing is that the tools are the smaller part of the engagement. Flyway can be installed in an afternoon. Getting a schema whose authority is a running server into version control, and getting the change patterns to a state where the pipeline can apply them online, is the work — and it is the same work whichever migration tool applies the result.
Tool to step
Which tool carries which step of the practice
The five steps are the database DevOps sequence; the middle column is what Redgate’s tooling contributes to each, and the right column is what it cannot do for you. Product names and scope are as of this page’s last update; the vendor’s documentation is the authority on the products.
| Step | What the tooling does | What stays engineering work |
|---|---|---|
| Establish the truth | Schema comparison captures what is in each environment; source control tooling puts the SQL Server schema under version control with the drift reported | Deciding which differences between environments were deliberate. The tool reports drift; someone has to rule on it. |
| Fix the change patterns | Nothing directly. Flyway applies whatever migration it is given, safe or not | All of it: expand-then-contract, backfills separated from switches, no destructive change in the same release as the code that stops using the old shape. This is the phase with the real return. |
| Automate the checks | Static analysis of migrations in the pipeline for blocking operations, naming and permission changes, where the toolset provides it | The rule set: which findings block a deployment in your estate, and which are warnings. A default rule set that blocks nothing is a formality. |
| Deploy through the pipeline | Flyway applies versioned migrations in order, records what was applied, and refuses to run out of sequence or against a target whose history does not match | The pipeline itself, the promotion path across environments, and the integration with the delivery tooling the application already uses. |
| Prove the rollback | Undo migrations can be versioned alongside forward ones and applied by the same mechanism | Writing a reverse that is actually safe for data, and exercising it somewhere other than production. A versioned undo that was never run is a plan to discover during an incident whether you had one. |
The delivery
From a running server to a versioned schema
-
Baseline
The production schema captured as the origin, every environment compared to it, and the drift ruled on. There is no reconstructing the history that was never recorded; version one is today.
-
Tooling into the pipeline
Flyway or the SQL Server toolset wired into the delivery pipeline the application already uses, so a database change is promoted the same way and by the same mechanism as a code change.
-
Checks that block
The analysis rules set for your estate, with the findings that stop a deployment agreed with the people who will be stopped by them.
-
Change patterns reworked
The existing schema’s change habits retrofitted to patterns the pipeline can apply online. Slowest step, largest return, and the one the tool cannot do.
-
Handover
Written standards, a rehearsed rollback, and enough transfer that the practice survives the person who introduced it. Where wanted, the platform is then operated on the managed service.
Readiness
What a Redgate implementation has to be able to show
A tooling implementation is easy to declare and harder to demonstrate. Each of these can be checked by someone who was not involved:
- The repository, not a server, is the authority for the schema, and a drift report says which environment disagrees today
- Every migration is versioned, applied by the pipeline in order, and recorded, and none reaches production by a console
- The analysis rules block at least one class of dangerous change, and the last blocked deployment can be named
- Every migration ships with its reverse, and the reverse was run in a lower environment before the forward one reached production
- A lower environment can be rebuilt from the repository by someone who has not done it before
- Non-production environments hold masked or generated data, and the masking is part of the pipeline rather than a separate favour
- The team that owns the database can explain the pipeline without the person who built it in the room
Where it sits
Redgate and the data practice around it
Database delivery tooling is one part of a data practice that also decides which platform an organisation should be on, moves data when that decision changes, and operates the platform afterwards. Redgate’s tooling belongs to the first of those concerns: the changes shipped every week against the platform you already have.
The neighbouring decisions are owned by other pages and handed over rather than answered twice. Whether to stay on the platform is data platform modernisation; moving between platforms is database migration, and the product that moves the records is iblync. Where the estate is a document platform rather than a relational one, the delivery problem changes shape, and the Couchbase page covers that half.
Non-production data
Where the tooling meets data protection
A copy of production is still production data
The ordinary way to get a realistic lower environment is to copy production into it, and for a database holding personal data that is a data-protection decision rather than an engineering convenience. Masking or generating test data is real work and it belongs in the pipeline, so that every rebuilt environment gets it automatically rather than by a favour from the one person who knows the script.
Redgate’s toolset includes data-masking capability for SQL Server estates; where it fits, it is wired into the environment rebuild. Where it does not, the masking is built as pipeline code. Either way the outcome is the same and it is checkable: no lower environment holds unmasked personal data, and the pipeline is what guarantees it.
What this page is
A statement of capability, not of status
This page says what Interkey does with Redgate’s tooling: implementation inside a database delivery pipeline for organisations in Saudi Arabia, delivered from Riyadh. It makes no statement about any formal programme, tier or certification, because the site publishes relationship claims only where the evidence for the exact wording is on file, and for this technology it is the capability that is on file. Flyway and the SQL Server toolset are products of Redgate Software; the vendor’s own documentation is the authority on what each does.
Buyer questions
What buyers ask us
Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.
Is Redgate an Interkey product?
No. Redgate is a technology Interkey implements, in the same family as Datadog, Couchbase, Docker and Kong on this site. Interkey’s own products are on the products page; the one closest to this topic is iblync, which moves data between platforms rather than delivering changes to one.
Do we have to use Redgate to work with Interkey on database delivery?
No. The practice is tool-agnostic and says so, and an estate already committed to another migration tool is not asked to change it. Redgate’s tooling is what Interkey implements when the estate has no tooling, or when the estate is SQL Server and the comparison and monitoring toolset earns its place.
Which databases does this cover?
Flyway covers the mainstream relational platforms; the comparison, source-control and monitoring toolset is SQL Server’s. Exactly which platforms each product supports in which edition changes, and the vendor’s documentation is checked at scoping rather than restated here.
How long does an implementation take?
The baseline and pipeline wiring are a matter of weeks. The change-pattern rework is the long part and is paid down schema by schema rather than in one programme, which means the value arrives incrementally rather than at the end of something that might be cancelled. The practice page says the same thing, because it is a property of the work rather than of the tool.
Read next
Explore related solutions
Next step
Discuss a database delivery pipeline
Say which platform, how often the application ships, and how a schema change reaches production today. Whether the tooling is the answer follows from those three.
-
Migrations versioned and pipeline-applied
Nothing reaches production by a console
-
Rollback exercised before it is needed
In a lower environment, every time
-
Delivered on the Saudi working week
Riyadh engineering, Sunday to Thursday