deployment

Stairway icons Database Deployments

Stairway to Reliable Database Deployments Level 2 - Defining the Deployment Contract

  • Stairway Step

Level 2 formalizes the behavioral guarantees that a changeset must provide in order to be safely deployed and rolled back. It introduces the deployment contract, checkpoint semantics, and the structural scope of Create and Rollback scripts. Data changes are addressed through a dedicated Update mechanism, with clear boundaries and limitations. By the end of this level, a changeset becomes a predictable and well-defined unit that can be reasoned about independently of execution context.

★ ★ ★ ★ ★ ★ ★ ★ ★ ★

You rated this post out of 5. Change rating

2026-05-06

753 reads

Stairway icons Database Deployments

Designing Database Changes Before Deployment: Level 1 of the Stairway to Reliable Database Deployments

  • Stairway Step

Stairway to Reliable Database Deployments introduces a progressive approach to managing database changes with clear intent, predictable rollback, and explicit behavioral guarantees. Starting from change design and moving toward execution and coordination in complex environments, the Stairway provides a conceptual framework for deploying database changes safely and consistently, independent of specific tools or automation platforms.

★ ★ ★ ★ ★ ★ ★ ★ ★ ★

(1)

You rated this post out of 5. Change rating

2026-04-15

1,480 reads

External Article

Database Lifecycle Management: Deployment and Release

  • Article

So often, the unexpected delays in delivering database code are more likely to happen after the developers initiate the release process. The necessary checks and tests can turn up surprises: The handover process can expose deficiencies. With good teamwork, planning and forethought, though, the process can be made almost painless.

2016-08-05

4,063 reads

External Article

Database Deployment: The Bits - Agent Jobs and Other Server Objects

  • Article

Databases often need more than just the database objects to run. There may be certain server objects and components, and SQL Agent objects, that are required as well. For an automated deployment, these need to be identified and their build script placed in source control. They then need to be deployed via the pre, or post deployment script. Phil spells out how and why.

2013-05-29

2,424 reads

External Article

Database Deployment Challenges

  • Article

There are a number of challenges that make the deployment task more difficult. Alex reviews the common techniques for deploying new databases and upgrading existing ones, and their flaws, and argues the advantages of an automated, incremental, script-based approach to deployments.

2013-03-18

3,067 reads

Blogs

T-SQL Tuesday #199 Invitation: Back to on-prem?

By

It’s time for T-SQL Tuesday again! And we’re almost to number 200! T-SQL Tuesday...

Data Skew in Data Engineering: What It Is and How to Fix It

By

You kick off a distributed job expecting it to finish in minutes — but...

Error Deploying GraphQL in Fabric: dm_exec_describe_first_result_set

By

A while ago we suddenly had an error while trying to deploy one Fabric...

Read the latest Blogs

Forums

Secure Cached Plans

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Secure Cached Plans

Complex Data Processing with dbt Python Models: The Fabric Modern Data Platform

By John Miner

Comments posted to this topic are about the item Complex Data Processing with dbt...

Over or Under Provisioned

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Over or Under Provisioned

Visit the forum

Question of the Day

Secure Cached Plans

The DMV, sys.dm_exec_cached_plans, contains rows for each cached plan on an instance. In Azure SQL Database, not every used has rights to every database, as there does exist an instance behind each database. How is security handled for this DMV in Azure?

See possible answers