As the previous section illustrated, it is important to think about how and when changes to the database schema or the application (or applications!) that use that schema are applied. But no matter how the deployment of schema changes and code deployment are scheduled, there will always be a period at which one of the following is true:

• The new application code is already running while the schema changes are not applied yet or are in the process of being applied.
• The old application code is still running while the schema changes are already applied or are in the process of being applied.
• The application code is not running while the schema changes are being applied.

The third situation is highly undesirable. This is true in general, but especially when practicing DevOps. If changes are shipped often and during working hours, it is unacceptable to take the application down for every schema change.

To prevent having to take the application down while schema changes are being applied, one of the following conditions has to be met:

• The schema changes are backward-compatible in such a way that the old version of the application code can run without errors against a database where the schema changes have already been applied, or are being applied.
• The new application code is backward-compatible in such a way that it can run against both the old and the new versions of the schema.

Meeting the first of these conditions ensures that the old application code can continue to run while the schema changes are being applied. Meeting the second of these conditions ensures that the new version of the application code can be deployed first, and once that is completed, the database can be upgraded while this code is running. While either will work, it is often desirable to aim for the first condition. The reason is that schema changes often support application code changes.

This means that the following is a safe process for deploying schema changes without downtime:

1. Create a new database.
2. Apply the database changes.
3. Verify that the changes have been applied properly, or abort the deployment pipeline.
4. Deploy the new application code.

It is important to realize that this process assumes failing forward. This means that if there ever is an issue with the deployment of schema changes, they should be resolved before going forward with the code changes.

Finally, meeting the condition of backward combability for schema changes can sometimes be impossible to fulfill for a schema change. If this is the case, the change can often be split into two partial changes that together have the same end result, while they both meet the condition of backward combability. For example, renaming a property, or changing the unit in which it stores a distance from feet to meters, can be executed as follows:

1. Generate a migration that adds a new column to a database table, storing the distance in meters.
2. Add an application code that reads from the old column, but writes to both columns.
3. Deploy these changes to production.

4. Add a new migration that migrates data from the old column to the new column for all cases where the new column is not yet filled, but the old column is.
5. Update the application code to read and write only the new column.
6. Deploy these changes to production.
7. Add a new migration that removes the old column.

Using the correct tools and a proper process, it is possible to execute effective and safe deployments of schema changes. In the next section, another approach, using schema-less databases, is introduced.