Migrations for non db changes?

What do you think about using migrations for non-db changes, that needs to be performed? I’m wondering why the focus is just on db migrations. E.g. some code changes could require an update in main-local.php or params-local.php or in the file system. So far I’ve done such changes manually. And I guess there is no other way.

Is it, because it is hard or nearly impossible to change php files? I wouldn’t know how to do this, but there might be a clever solution already.

Are you doing such changes manually as well? Or how do you do it? Can it be avoided? To be honest, it might be possible that I’m doing things wrong, so I just get the impression that there is something difficult, whereas others don’t have any problems…

I think that migrations are to be used where VCS (version control system) has no direct means to update (or revert the changes of) the running environment. Migrations make it possible. And a very good thing is that you can store the migration scripts in VCS repository.

In other words, where you could easily track the changes with VCS, there would be no need to use migrations.

So, I usually use migrations for db schema and RBAC settings.

RBAC settings can be stored in a file, not in db. But migrations can do things right even if it is stored in a file. Migrations are not limited to db-related operations. As in a command-lineYii app, you could use all Yii and PHP functionality in them except fot the web-related feature.

As for the changes in main-local.php or params-local.php, you don’t want to include them in your repository. You may want to do it in migrations, and I think it’s possible. But, again, you don’t want your repository to include that specific migration script which clearly state how to change main-local.php or params-local.php. That brings you to the beggining. :sweat_smile:

Thanks for the reply! Yes, until now I use the migrations also only for db changes and rbac. Of course, stored in git.

I thought about that issue since I’ve just updated my server and forgot to update those -local.php files, what produced errors that I couldn’t identify immediately. Then I was wondering what I could do to not forget it the next time. Currently, I can only imagine to write it in the commit message, so it is stored in VCS. But going through the commit messages is also cumbersome. git tags (sematic versioning) might be better.

So I still don’t know, how to deal with the situation most suitable. Any further ideas welcome!

1 Like

Typically I have handled it in the past with two VCS systems, one for code and another one which is environment specific for configurations. You may be able to just use one VCS with separate folders for each environment. Of course this will also require a simple deployment script to copy the configurations over to the correct folders in the correct environment.

I also like your idea of putting some of these configurations in migration scripts. Besides DDL changes I also use migrations for DML changes across environments as below and has served well for me.

    public function safeUp()
        switch (Yii::$app->params['frontendUrl']) {
            case 'http://dev.example.com': // Development
                echo "Development", "\n";
            case 'https://test.example.com': // Test
                echo "Test", "\n";
            case 'https://stage.example.com': // Staging
                echo "Staging", "\n";
            case 'https://example.com': // Production
                echo "Production", "\n";

I would hesitate to update the configuration files with “native” file handling. I found PHLAK / Config library to update configuration files. This will also make the changes readable and clear.

1 Like