0

Overview

I have an application that uses Doctrine migrations. The application is a software code base used to manage multiple businesses who all use the same code instance in their own unique environments. i.e. Each code base is identical other than configurations.

Mistakes we made

One of the mistakes the dev team made was to include core migrations in the customer folders. i.e. With each new application we have to drop in the migration files or run a migration:diff to get going which I feel is not efficient and can lead to a mess.

What I would prefer is to have core migrations as part of the core code since it rarely changes and custom migrations on the client app side.

What I want to do

  1. I want to move all core structure migrations to our code files
  2. I want to have a single custom migration to drop in customised data in the client migration folder.

The problem

The problem I face is pretty much how to reorganize the migrations without breaking databases on existing client applications.

I have thought of two solutions:

Solution 1:

  1. Add blank migrations as a placeholder for the new migrations I want.
  2. Commit these to the repo and deploy to our environments.
  3. They will be run, nothing will be changed, the migraitons table will store them as having been executed.
  4. Next, Update the blank migrations to the actual code I want, and empty all other migration files. Commit this to the environments.
  5. Finally - remove the unwanted migration files, remove the unwanted database migration records.

Solution 2

  1. Change the migration location in the db to a new location
  2. Remove all migration files and add blank migrations for the new ones I want
  3. Commit this to the repo, allow to run and record the migrations as being run in the new table.
  4. Add migration code.

Now all new applications will have the updated migration files and the old apps will have the new migration files...

Question:

Am I re-inventing the wheel? Is there a standard on how to do this as I am certain I am not the first to bump into this problem?

HappyCoder
  • 5,985
  • 6
  • 42
  • 73

1 Answers1

0

So for anyone who finds themselves in a similar position where they need to tidy up a mess of doctrine migrations, this should serve as a simple pattern to follow.

In our development environment we use continuous integration/git/kubernetes etc. and the following process works well with our environment.

The steps:

  1. Update the migrations table name, this you can do in the configs quite easily.
'table_storage' => [
    'table_name' => 'migration_version',
    'version_column_name' => 'version_timestamp',
],

  1. Next, delete your old migrations (delete the files) and run migrations:diff to generate a new one which will be a combination of all your changes.

  2. Now comment out the code in the new file so that it's essentially an empty migration file.

  3. On local, delete the old migrations table and run your build process which will add the new migration to the new table.

  4. Commit to develop/staging/live etc. and repeat the process.

  5. Now that the db in all your environments has the updated migrations file in it. You can now uncomments the code which will not be executed when you commit the file since it exists in your migrations table.

  • Hope this helps someone!
HappyCoder
  • 5,985
  • 6
  • 42
  • 73