Database migrations and dev/master branch

Yii 1.1 General Discussion
1

In our current setup, we apply bug fixes on the master branch and new features in the develop branch. Both bug fixes and new features can require database migrations, but the develop fixes should always be run after the bug fixes. This means that timestamp might not be the ideal solution to order a migration. What other alternatives are there, except a manual number? Manually label your migration causes a lot of conflicts when multiple people work at the same time; you might require to change your number multiple times before a merge.

Suggestions:

  • Both a manual number and a timestamp, to reduce risk of conflict
    Edit: Someone suggested to prefix the timestamp with the semver number used for versioning. Example: 5.1.0-20210101_180203
  • Let the timestamp of a develop migration start at the planned release of the develop branch (8 week interval, rolling release schedule)

Other ideas…?

2

Hi ollehar, you could create 2 distinct migrations folders, one for bugs and other for develop, then you could configure a controller mapping to the migration classes and each of their paths, then just call them with something like this:

./yii migrate-bugs
./yii migrate-develop
3

Hm. Would that require moving files when merging develop into the master branch? This happens at each release.

4

The files would be added in develop branch and merge into master when ready. Your folder structure would look like this:

/migrations
> /bugs
>> m2021_020121_bug1.php
>> m2021_060121_bug2.php
> /develop
>> m2021_040121_develop1.php
>> m2021_050121_develop2.php

Another solution would require some experience with CI/CD tools, which can enable running only the migrations (for develop or for master), but this goes beyond my experience.

5

Hm, how would this work under a one-year period, with a release every 8 weeks and people updating along the way? I have to think now. :thinking: :slightly_smiling_face:

6

Haha That’s a dificult one.
The best answer is to implement a CI/CD were you can run migrations separated from the deploy.

But here, we use a similar folder struct to that, the only caveat is maintaining both “migrations” decoupled, where migrating one folder wouldn’t impact negatively on the other.

7

Our application is similar to WordPress, in that we offer both hosted and self-hosted solution, and it’s open-source, so not always easy to know what people will do.