Cleanup and Deploy Like the Pros

Removing shims

I always tell my kids that a job isn’t done until the tools are put away. Way back in the preparation phase, we applied the database expansions and added shims. The time has come to finish that task.

Removing shims is the easy part. Once every instance is on the new code, those triggers are no longer necessary, so we can just delete them. Do put the deletion into a new migration, though.

Contraction

It’s also time now to apply another round of schema changes. This is contraction, or tightening down the schema:

• Drop old tables.

• Drop old views.

• Drop old columns.

• Drop aliases and synonyms that are no longer used.

• Drop stored procedures that are no longer called.

• Apply NOT NULL constraints on the new columns.

• Apply foreign key constraints.

Principle of undetectability

Most of those are pretty obvious. The exceptions are the two kinds of constraint. We can only add constraints after the rollout. That’s because the old application version wouldn’t know how to satisfy them. Instances running on the old version would start throwing errors on actions that had been just fine. This breaks our principle of undetectability.

It might be easy for us to split up our schema changes this way. If we use any kind of migration framework, then we’ll have an easier time of it. A migrations framework keeps every individual change around as a version-controlled asset in the codebase. The framework can automatically apply any change sets that are in the codebase but not in the schema.

Modeling tool to create schema

In contrast, the old style of schema change relied on a modeling tool or sometimes a DBA acting like a modeling tool to create the whole schema at once. New revisions in the tool would create a single SQL file to apply all the changes at once. In this world, we can still split the changes into phases, but it requires more effort. We must model the expansions explicitly, version the model, then model the contractions and version it again.

Whether we write migrations by hand or generate them from a tool, the time ordered sequence of all schema changes is helpful to keep around. It provides a common way to test those changes in every environment.

For schemaless databases, the cleanup phase is another time to run one shot. As with the contraction phase for relational databases, this is when we delete documents or keys that are no longer used or remove elements of documents that aren’t needed anymore.

Cleanup phase

This cleanup phase is also a great time to review our feature toggles. Any new feature toggles should have been set to “off” by default. The cleanup phase is a good time to review them to see what we want to enable. Also take a look at the existing settings. Are there any toggles that we no longer need? Schedule them for removal.

Deploy like the pros

In those old days of the late 2000s, deployment was a completely different concern than design. Developers built their software, delivered a binary and a readme file, and then operations went to work. No longer. Deployments are frequent and should be seamless. The boundary between operations and development has become fractal. We must design our software to be deployable, just as we design software for production. But great news! This isn’t just an added burden on the already-behind-schedule development team. Designing for deployment gives you the ability to make large changes in small steps.