2

Should Database migrations be in included in the same deployment project as the code?

If they are not included in the same deployment, the Database deployment package and the Code deployment package will get different version numbers and this will generate confusion trying to figure out which Database version corresponds to which code version.

Note that our sql migration scripts are completely independent and unrelated to the code. We are just tying the sql scripts and code to the same deployment package, so they have the same version number.

Some people have the opinion that this is a bad practice, but looking carefully at their reasons in the following articles, they don't explain it very well and though they're not able to convince me:

Decoupling-database-migrations-from-code-deployments

Database-migrations-done-right

What do you think?

5
  • "We are just tying the sql scripts and code to the same deployment package, so they have the same version number" sounds like a good enough reason to me. Mar 22, 2018 at 15:09
  • "our sql migration scripts are completely independent and unrelated to the code." Are you saying you could deploy separately and never have an issue?
    – JeffO
    Mar 22, 2018 at 19:37
  • Hi @JeffO, I'm saying we could deploy separately and we could have issues if we don't figure out which database version corresponds to each code version. Am I clear? Mar 22, 2018 at 21:04
  • 5
    Sounds like your sql migration scripts are, in fact, completely dependent and related to the code. Mar 22, 2018 at 22:30
  • First link isn't working any more, could not find even find it at archive.org.
    – Doc Brown
    Dec 23, 2019 at 8:07

4 Answers 4

1

In my experience, if the database is only connected via a single application such as a micro service api or monolithic app with one db, it does make sense to have code and db changes lock-step to avoid incomplete deployments.

If you have a database in which there is no single "owner" application, separation and manual synchronization makes sense to ensure proper order of changes.

1

If they are not included in the same deployment, the Database deployment package and the Code deployment package will get different version numbers and this will generate confusion trying to figure out which Database version corresponds to which code version.

This works fine if you have a single DB node, and a single application node.

However once you have clusters of DB nodes to migrate, and clusters of application nodes to run, you are going to have difficulty trying to keep the same version of DB code corresponding to the same version of an application node. This is especially so when you are doing rolling deployments of new application / DB migration scripts to your clusters. There will be a brief period of time whereby new application code is accessing old database schema, or old application code accessing new database schema.

The best way to deal with this is not to tie app deployment with DB migrations, but to support backward compatibility until old code / schemas can be safely dropped.

0

I had the same question after joining a team with a strict policy separating code and database migrations. The primary motivation was to avoid a situation where old code pointed to a new database schema. For example, imagine cloned servers used in load-balancing.

Why should I keep my migrations backward compatible?

That image is taken from an article by another team. They summarise the benefits well. I would say that item 1 is the real reason, and items 2 and 3 are beneficial consequences.

We decided to keep those migrations backward compatible for the reasons:

  1. It enables us to do zero-downtime deployment (“blue-green” deployment)
  2. We can switch between branches during development without getting errors.
  3. Decoupling the code version from the database version is in general a good idea

From Keeping Django database migrations backward compatible

-1

Short answer is yes.

This post has the answer I was looking for:

is-it-okay-to-integrate-database-migration-tools-like-flyway-liquibase-with-the-code

1
  • If this has the same answer, it may be a duplicate question just cross posted on another site.
    – JeffO
    Mar 23, 2018 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.