Database DevOps · Redgate Flyway

Database CI/CD in Saudi Arabia: schema changes through the same pipeline as your code

Database CI/CD means every schema change is built, checked and deployed by a pipeline, like your application code, with a record of what ran where. Interkey builds it for organisations in Saudi Arabia with Redgate's Flyway, inside the GitHub, GitLab, Azure DevOps or Jenkins pipeline you already run, and supports it from Riyadh.

Plan a database CI/CD pilot Take the maturity self-check

In short, for executives

The problem: applications ship weekly, but database changes wait for a window and a person with a console.
What changes: each schema change is versioned, checked automatically and applied by the pipeline, with a record.
The tool: Redgate Flyway, as a step in your CI/CD tool. Flyway Enterprise adds drift detection, change reports and policy checks.
What Interkey does: baseline, pipeline, checks, rehearsed rollback, handover and support from Riyadh.

At a glance

Database CI/CD with Flyway at a glance
Question	Answer
What it is	CI/CD for schema, reference data and permissions
Tool	Redgate Flyway; Enterprise where drift and change reports are needed
Where it runs	Your existing pipeline: GitHub Actions, GitLab CI/CD, Azure DevOps, Jenkins
Databases	More than 60 platforms by Redgate's count, including SQL Server, PostgreSQL and MySQL
Evidence for audit	Versioned migrations, a history table, change and drift reports
From Interkey	Baseline, pipeline, checks, rollback, handover, support from Riyadh

What database CI/CD has to cover

A database cannot be rebuilt and replaced like an application package, because it holds data. So a database CI/CD pipeline has to do four things an application pipeline does not:

Know the target. Know which version each database is at, and stop if it has drifted from the repository.
Apply changes in order, once. Each migration runs once per environment, in version order, and is recorded.
Check before it deploys. Blocking operations, missing indexes, permission grants and naming are checked on every change, leaving design questions to the reviewer.
Have a way back. Every change carries its reverse, already run in a lower environment.

The database DevOps practice explains why the order matters: automating deployment to a database nobody can describe only makes mistakes faster. CI/CD is built on database version control.

Where are you today? A maturity self-check

Redgate describes database lifecycle management in four stages, each building on the one before. Most estates sit at different stages for different databases.

Self-check against Redgate's four-stage database lifecycle maturity model
Stage (Redgate's model)	What it looks like	Ask yourself	Next step
1. Manual	Changes written by hand and applied through a console; scripts in a shared folder	Can anyone say with certainty what is in production now?	Capture a baseline and run a drift check
2. Automated version control	Schema, reference data and permissions held in a repository; unrecorded changes are flagged	Is the repository, not a server, the authority for the schema?	Add a CI build that applies every migration to a clean database
3. Continuous integration	Each commit builds and checks the database changes automatically, with tests	Does a broken migration fail the build before anyone reviews it?	Deploy through the pipeline to test and staging
4. Release management (automated deployments)	The same migrations promoted through every environment by the pipeline, with approvals and records	Did the last production change reach the database without a console being opened?	Prove the rollback and hand over the standards

Stage names are Redgate's, from its database lifecycle management overview, read on 10 November 2026; Redgate's article also includes monitoring at every stage. The questions and next steps are Interkey's.

How Flyway plugs into GitHub, GitLab, Azure DevOps and Jenkins

Flyway does not replace your CI/CD tool. Redgate's documentation says it runs from the command line, Docker or an API, so the pipeline calls it as one more step, and Redgate lists GitHub Actions, Azure DevOps, GitLab CI/CD, Jenkins, TeamCity, Octopus Deploy, Bitbucket Pipelines and AWS CodePipeline among the tools it runs in. The database steps sit beside the application steps:

On every commit (CI): Flyway applies all migrations to a clean build database and runs the checks. A failing migration fails the build.
Before a deployment: Flyway compares the target with the repository, reports drift and lists the changes about to run, for an approver to read.
On deployment (CD): Flyway applies the pending migrations in order and records each in its history table, flyway_schema_history by default.

So a GitHub Actions database workflow, an Azure DevOps database deployment stage and a Jenkins job use the same migrations, checks and approval gates as the application. Credentials stay in your secret store.

Flyway Community covers versioned migrations and pipeline use; drift detection, advanced change reports, policy-as-code checks and change history for audit are listed for Flyway Enterprise. See the Flyway editions page and our Flyway Enterprise page.

Change reports and drift detection for audit

Regulated organisations have to show who changed what, when, and who approved it. A manual process keeps that record as paperwork; a pipeline produces it while it deploys, more completely.

Redgate's documentation describes a Flyway check command with four reports: the changes about to be deployed, drift between the target and the applied migrations, a dry run of the deployment script, and code analysis. They come out as HTML and JSON, so the pipeline attaches them to each run. Redgate lists drift and changes reports for the Enterprise edition.

With the history table and the pipeline's approvals, an auditor can check what was reviewed, what ran, and whether any environment has changed since. A person still decides whether a drift was deliberate; the tool reports it but does not rule on it.

Where teams use database CI/CD

SQL Server CI/CD. SQL Server databases whose changes a DBA scripts and applies at night. Flyway and Redgate's SQL Server toolset handle comparison and versioning; see Redgate implementation.
Many teams, one database. Version order and the history table stop two teams' changes colliding in production.
Drifted environments. The pipeline promotes the same migrations through development, test, staging and production, and reports where they differ.
An audit finding. The pipeline's records answer a request for evidence of database change control.
A migration programme. When a database moves to a new platform, the new target should be under CI/CD from day one.

The Saudi context: test data, records and local support

Two things shape database CI/CD in the Kingdom. First, a CI build needs data, and the easy answer is a copy of production. Where that copy holds personal data, Saudi Arabia's Personal Data Protection Law, overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA), applies to it as to production. Build and test databases should hold masked or generated data, with the masking in the pipeline; see data masking for test environments. Second, the pipeline's record is the evidence internal audit asks for, so approval steps are designed with them from the start.

Interkey's engineers work from Riyadh, in Arabic and English. The pipeline runs on your own tooling and infrastructure, so your databases and data stay where they are.

How a database CI/CD project runs

Redgate makes Flyway. Interkey does the work around it: version control, the pipeline, the checks and the change habits that let the pipeline apply changes safely. Installing Flyway is the small part. We quote Redgate licensing at the vendor's terms beside our work, in one proposal.

Capture the baseline.

Record production as version one, compare every environment and rule on the drift.
Pilot on one schema.

Wire Flyway into the existing pipeline and run it to a lower environment.
Set the checks.

Agree which findings block a deployment, with the people who will be blocked.
Deploy through every environment.

Promote the same migrations to production, with approvals and reports at each gate.
Prove the rollback and hand over.

Run each reverse in a lower environment, write the standards and train the team.

What drives the cost and the timeline

The cost has two parts: Redgate's licence, on Redgate's terms, and Interkey's implementation, scoped per programme. We print no prices. What moves both:

Edition: Enterprise for drift, change reports and policy checks, or Community under Redgate's licence terms.
Databases and platforms: one SQL Server schema is a different job from forty databases on three engines.
Drift: the baseline is quick where environments agree and slow where they do not.
Change patterns: reworking changes that need a maintenance window is usually the longest and most valuable part.
Approvals: gates that must match an existing change process take time to agree.

As an estimate, a pilot on one schema takes weeks; we give a timeline for the full estate after the assessment.

What a pipeline will not do: it applies whatever migration it is given. It makes changes visible and recorded; it does not make a destructive change safe or tune a slow query. Safe change patterns remain engineering work.

Questions buyers ask

What is database CI/CD, and how does it differ from CI/CD for application code?

The same idea, applied to schema, reference data and permissions. Because a database holds data, the pipeline must also know the target's version, apply each change once in order and carry a tested way back.

Can Flyway run inside the Azure DevOps or GitHub Actions pipeline we already use?

Yes. Flyway runs from the command line or Docker, so it is a step in your pipeline; Redgate lists Azure DevOps, GitHub Actions, GitLab CI/CD and Jenkins. Your approvals and secret store stay as they are.

How much does database CI/CD cost for a company in Saudi Arabia?

Two parts: the Redgate licence, on Redgate's terms, and Interkey's implementation. The number of databases, the edition and the drift move the figure most. We quote both in one proposal after a short assessment.

How long does it take to put our databases under CI/CD?

As an estimate, a pilot on one schema takes weeks. The full estate depends on the databases in scope, their drift and how many changes still need a maintenance window.

Will the pipeline give our auditors a record of every database change?

Yes, if designed for it: reviewed migrations, the approval, the history table entry and, with Flyway Enterprise, change and drift reports. We design the gates with your internal audit team.

Can Interkey run the database pipeline for us from Riyadh after go-live?

Yes. Our engineers in Riyadh can operate it as a managed service under a written scope, or hand it over with standards and a rehearsed rollback. Redgate provides product support under the licence.

Next step

Plan a database CI/CD pilot

Tell us your database platforms, your CI/CD tool and how a schema change reaches production today. We will suggest the first schema for a pilot.

First name Last name

Company Email Company

Phone number (optional) Your databases, your pipeline and how changes ship today

Required field

By sending this form, you agree to our Privacy Notice.

Published by Interkey. Last updated 2026-11-10. Interkey is registered in Riyadh, Saudi Arabia under commercial registration 1010156897.

Capture the baseline.

Pilot on one schema.

Set the checks.

Deploy through every environment.

Prove the rollback and hand over.

Plan a database CI/CD pilot