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?

  • "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. – Robert Harvey Mar 22 '18 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 '18 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? – Miguel Domingos Mar 22 '18 at 21:04
  • 3
    Sounds like your sql migration scripts are, in fact, completely dependent and related to the code. – Robert Harvey Mar 22 '18 at 22:30
  • First link isn't working any more, could not find even find it at archive.org. – Doc Brown Dec 23 '19 at 8:07
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.

0

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.

-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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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